Right. Good afternoon, everyone. Thank you for coming out. We're here to talk today about Aconda, which is a new open source, production ready open source network virtualization platform. I am Jonathan LeCour. I am the vice president of Cloud at Dreamhost. Dreamhost is a service provider. We've been in the web hosting and cloud services business for about 16 years now. Have over 400,000 customers. And we've got some really great cloud products built on OpenStack and Ceph. My background is engineering. I've been programming since I was 15 years old. I've been using Python since 1.4, which is a really long time. And I'm a member of the Python Software Foundation. I've been using OpenStack and been involved in OpenStack since the Diablo days. And this is my cohort, Ryan. Hey, everyone. I'm Ryan. I also work at Dreamhost, where I've been for about three years now. I'm a veteran of Python software development. I've got some experience with Python service-based startups in the past. And I work on Aconda at Dreamhost. So let's talk about what we're going to actually be doing today. We've got a lot to cover, so I want to give you guys a little bit of road maps, where we are. So first, I'm actually going to talk about not Aconda. I'm going to talk about some context, some history around why Aconda was born, and why we needed it, and how we developed it. I'm going to introduce the technology a bit. And then Ryan's actually going to dive very deep into what makes Aconda tick, and how the actual platform works. And then we'll talk about operations as well. So we actually use Aconda in production today in our OpenStack Cloud to provide all the Layer 3 plus services in our compute platform. So we have a lot of experience operating it. So we want to share some of that as well. And then we'll do a little bit of a retrospective. Talk about some of the decisions we made, both good and bad and why. And then we'll talk about the exciting future that lies ahead of Aconda. There's some really cool news that came out yesterday about it. So we'll start off with some emoji here. Did anyone know there was a little baby's head in emoji? I thought that was pretty funny, so I tossed it in there. We'll talk about the birth of Aconda. So that starts by talking about something other than Aconda, Dream Compute. Dream Compute is Dreamhost OpenStack Public Cloud. It's been a long journey to get it out. We are in public beta as of last week. So you can go to our website and sign up right now and consume our OpenStack Cloud. It's really cool. It is built on top of OpenStack, as I mentioned, and on top of Ceph, which we use for block storage. Ceph was actually born at Dreamhost. It was technology created by one of our co-founders, Sage Weil. We developed it in-house for some time and incubated it. And then we spun out a company called Ink Tank that you may have heard of and sold them to Red Hat earlier this year, I guess. So it was a very cool and interesting story there, and it's been an interesting segue into Aconda for us. Similarly, we developed Aconda in-house to provide some of the networking for Dream Compute. So it's KVM hypervisor. You guys all have seen.  I think you guys know how it all works. The interesting thing about Dream Compute is we had some design tenants that were, some would say a little bit aggressive, but very interesting and very principled at the beginning of the project. We really, really wanted to provide every tenant in our public cloud with complete L2 isolation. We wanted to do that in a scalable way and in a way that would last for many years. So we didn't wanna use a lot of the traditional ways to do that. We really wanted to have virtual L2. So we also know as a smaller provider, we don't have an unlimited bank of IPv4 addresses and we also can count and know that there aren't that many of them. So the future is IPv6 and we wanted IPv6 capability natively from the beginning.  This was before Neutron existed. So there was no open source solution to provide us with what we wanted. We went out to a vendor and we got L2. We went to a company called NYSERA. They're now VMware and they have NSX. It's a great product. Great guys, we love working with them. And it was really working well for us but we needed Layer 3. We needed something to provide all the routing and other services to our tenants in Dream Compute. First thing we did, being Dreamhost, founded on open source software, built on Linux Apache, MySQL, so on. We wanted an open source solution and we didn't really find anything that fit the bill. There were some things out there but many of them were being controlled by vendors who didn't necessarily understand open source or cloud, didn't understand the model and didn't support IPv6, weren't interested in supporting IPv6. So we just thought, how hard can it be? Let's do this on our own, right? Words of folly that everyone has uttered, every engineer has uttered in their time. So that born, that birthed a conda. And when we first started out, the idea was we were gonna run OpenBSD in a service VM inside of each tenant, plug it into their V-switch, use packet filter, PF to provide all the services that we need, build a little API and it would be really easy. And turns out it's really hard, really, really hard. As we went forward, we realized we had made some missteps, we iterated and iterated, tested and tested and came to kind of the model that we're at today. So we determined that OpenBSD was not really well suited for our use case. So actually if you had looked at the talk description, I think it still mentions OpenBSD as the foundation. And it was for a long time and we got very far with it. It's a great OAS, we love OpenBSD, but it wasn't quite perfect for our task. So there was some community resistance in OpenBSD to virtualization. When you go into the OpenBSD kind of mailing list and mention that you're doing things that avert environment, it's not as accepted as it is in say Linux. We had some issues with drivers and some network throughput and under a virtualized NKVM, booting an OpenBSD image was taking three to five minutes which is a very long time for our opinion. And also we needed hot plugging to do some other features that we were interested in and it wasn't quite working well for us in OpenBSD so we were having to reboot routers and service VMs whenever we wanted to do certain things like add networks. And everything else is Linux, so naturally we decided to switch to Linux. Now at the time we already had a condo working and it was just a matter of spending a brief period of time and by spending a brief period of time, I mean locking Ryan in a room for a few weeks and moving over. So we switched from OpenBSD to Linux, from packet filter to IP tables and we got a much larger community, a lot of support, a lot of knowledge we already had in the house around IP tables, we got better performance and now we can build and reboot service appliances, service VMs in about 45 seconds which is a much more acceptable kind of time period. And we also got hot plugging support and Ryan will address why that's interesting in a little bit. So as we start slicing down here, let's look at the architecture for a condo and kind of how it works at a high level. This is the current architecture and there are boxes in here that I'm not gonna touch on right now. But the idea basically is that a condo has this service VM that runs inside the tenant, as I mentioned and it can provide a variety of virtual services. You could call this NFV if you want to, that's fine. I kind of prefer to think of it as service virtualization, network service virtualization. So we've got routing, additional services and development and then we plug into the OpenStack APIs, some extensions to Neutron and we have a back end right now on top of our VMware NSX L2. We realize that other people may not want to use VMware, they may want to use something else. So we're gonna work on pluggable back ends there. We'll talk about that more in a bit as well. And the thing that kind of is the hub in the whole model is this orchestration platform called the rug. That used to stand for a thing but we'll get into what that stands for now. So before we jump into depth on the technology, let's talk a little bit about whether or not this was all worth it. At the end of the day, Dream Compute, it works really well because of Aconda and we're very excited about that. It was not an easy decision. We actually have done bake-offs between Aconda and some other technologies that are out there these days and it still is beating everything else for our use case. That's not to say the other ones aren't good, they're great. And IPv6 support came right there out of the gate for us and that was very important to us. So now if you sign up for Dream Compute, you spin up a virtual machine, it will get an IPv6 address and an IPv4 address. Everybody gets them, it's included in it. And it's really open, it's not sort of open or we throw the source code over the wall every once in a while, it's up on GitHub. You can see every commit we make, you can contribute yourselves. And also it's just Linux, right? This is a beautiful thing. When it's just Linux, you can run anything you want on these service VMs. So it opens the whole world to all these additional network functions that we can add to the platform. And stability, it's working today, it's in production. Customers are using it every day. So big wins. Now Ryan is actually gonna talk about in depth how Aconda actually works. Thanks, John. So Aconda is primarily composed of two major components. Like John mentioned, there's the service VM itself, which is a VM running Linux and a variety of services. And then there's also the rug, which is the service that orchestrates, monitors, and manages these service VMs. So let's start out by talking about the appliance. So we build these appliance images with a piece of software called Veewee. Veewee isn't the only option, but it's the one that we've sort of built our tooling around. And so the Aconda appliance code really consists of the different pieces of software, the Python software that we've written, code for generating IP tables and DNS mask and bird configuration. And then Veewee is what we use to build the image and we then upload that in the glance. So some of the pieces of software running on the actual appliance, IP tables, we use that for tenant address translation, floating IP address translation, DNS mask, we're using for tenant network DHCP. In our cluster, we actually use config drive, so we don't make use of this, but it does work. Anytime somebody goes into a Neutron subnet and sets up static routes, custom DNS servers, that's all managed by DNS mask. John mentioned V6 support for all the instances in a tenant network. So we do upstream routing and address advertisement with bird. We use BGP and RADV. And then we also have some Python services running on these service VMs. So the first one is a Python proxy for Nova metadata. So if a customer spins up an instance with Nova, that instance is gonna look for metadata at a well-known address. We have on the router a piece of Python software that is running and is listening for those requests, proxies them over the management network so that it can speak with Nova and metadata can work for those instances. And then additionally, this is probably the bulk of the code that encompasses the appliance is a Python service that the rug speaks to. And so this does a couple of things. First of all, it's an HTTP endpoint that the rug can speak to that provides an alive check. So periodically, for every tenant's router, the VM will just ask, are you alive? Are you there? So that it can determine if it needs to be rebooted, if it's unresponsive, those sorts of things. And then also, there's the configuration push so that as users create networks, subnets, ports, plug things in, create VMs. In reaction to that, we are pushing across configuration updates that change settings on the router and reload services. Oh, I missed a slide. So this is sort of what that configuration push looks like. It's a JSON data structure. We've really condensed this down because I want to make sure that people can read it. But if you've worked with Neutron at all, this should probably look pretty familiar. There's a lot of information here about a network and its subnets, the sitter for the subnets, the interfaces and their addresses, floating IPs. So this is what gets pushed across. And as a result of this configuration push, we reconfigure different services and restart them. For the addresses, that might mean for specific interfaces, we add an address or remove an address. For floating IPs, it might mean that we change the IP tables rules that we're netting properly, restart IP tables or reload rather, setting the fault gateway, that sort of thing. For reference, this API is part of the reason that Ryan was so quickly able to change the underlying platform. We went from OpenBSD to Linux, and we were using this higher level API to say, here's what we generally want, and I don't care how you do it. I don't care that it's DNS mask, bird, IP tables, Linux, OpenBSD, whatever. So that's a big win here, why we're not just pushing across IP tables rules and things like that. I think implementation is pluggable too. So I mean, for instance, when we move from packet filter to IP tables, none of this had to change. We just had to write a new plugin that understood what it needed to do with IP tables. So that brings us to the rug, which we think really ties the room together. The three of you apparently who has seen Big Lebowski, I was expecting more of a chuckle, come on guys. I think we were debating the other day, I was like, does the rug actually stand for anything? We thought it stood for a router update generator, maybe? But not really, I think it just really ties the room together. It's the orchestration, it brings it all together. At one point, I think we had an internal service, we named the dude, but that... We still have a service called the dude as well, but it's not part of a condo. It doesn't actually mean anything, we just wanted to call it the dude. Lebowski's a part of every network virtualization platform that's quality, in my opinion. So the rug does orchestration and monitoring of the service VMs. So let's talk a little bit about the architecture of the rug. So it's a complicated piece of software, but we can probably condense it into three pieces. I'll start with the middle one, which is the event processing. So some of you have worked with Neutron know when you update ports, perform various actions in Neutron. Notifications and RPC messages are sent across generally your AMQP message bus. So the rug has a process which listens to the notifications that we care about and then performs actions based on those. And not just from Neutron, from Nova as well. Nova as well, yeah, but primarily Neutron. Right. So the event processing listens for these. Some of those examples might be a router interface create or a port create end. We actually dog food this ourselves a little bit. I'll talk about this later, but so we actually can send custom messages to the rug to tell it to do things. And that flows through this as well. So all the events come in through this notification system and they're sort of coalesced down into actions. So some of these are pretty obvious. If a router is created, then that's sort of a create. We've got read, update, delete, crud sort of oriented actions that this gets coalesced into. And as we receive these, we put them into a queue that is processed by a Python multiprocessing queue with a configurable number of workers. As those events are added into the queue, the second component of the rug, which is the state machine consumes them, looks at the current state of a tenant VM and then decides what to do next and transitions through these states. So if a create comes through, depending on the state of a router, the next action might be to boot a virtual machine through Nova. And then finally, health monitoring is another area where we sort of dog food this event processing. So there's a background process that runs as part of the rug and every minute or however many minutes you configure it to do so, it pushes an event in which is basically ask every router if it's alive, if it's responsive, if not, we need to take some action. So this is the state machine and I know you can't read it and I didn't intend for you to be able to read it because it's very complicated, I can't even read it. There are 10 states there and there are a lot of different transitions. It's very sophisticated. So I'm going to go through a couple of the potential use cases here so you guys can sort of understand what's gonna happen when different actions occur. So some of the ones we need to know about, there's a create VM state which does exactly what you would think it would do. There's a configuration state which is once a service VM is actually booted we need to push the configuration that we mentioned earlier, restart services. Periodically you may want to destroy one of these service VMs. So those are sort of the actions you would take to manage your virtual machine. There's another category which is collecting stats and usage. So you can pass messages into the rug which are, give me information about bandwidth consumption for this given tenants router. And so down the line I imagine we'll probably have some type of integration with salometer. Right, this would be great for say if you were running a large public cloud and you wanted to, I don't know, track bandwidth on a pertinent basis for billing purposes. And then the live check which is something I mentioned earlier. So here's an example flow through the state machine. All of the state machine transitions start at this calc action state which calculates the next thing to do based on the state. So this actually happens when a new customer is signed up for a cloud, a dream compute account. A router is created for them automatically that ends up turning into an event that we capture from Neutron. And as a result of that the rug has logic where it realizes okay, there isn't a VM for this person we need to go ahead and create it. So we transition to create VM. From there we transition into a state where we're checking to see if it has finished booting yet. And so you notice that I've actually got arrows between check boot and calc action here. So this is actually a process that continually goes back and forth. We say have we checked if we booted, if not we yield back and some more work can be done. Maybe a moment later, this event arrives in the queue again. Has it booted yet? And maybe about a minute later a VM has come up and we've actually booted it. We need to configure it. So that pushes the configuration that I mentioned earlier. We get a response from the API that says yes it worked, all the services restarted. And at that point we go back to calc action and we have a service VM that is live and ready to do its work. Now across time as people plug in networks, boot VMs, we're going to do something very similar to this only this time we won't be creating the VM we'll be going straight to config. So here's another example. This is the health monitoring that I mentioned earlier. Again we go into calc action and this time we're receiving an event which is pull the router. We go to the alive state and in this circumstance it looks like we're trying to reach the VM over the HTTP interface. It's non-responsive. We've waited maybe a minute or two and we decided okay let's kick it out, let's just make another one. So you can sort of see the direction that this is going here. We're going to stop it, create a new VM, check the boot and we sort of continue that cycle. So let's talk about a couple other interesting features that the rug has. One of those is network hot plugging. So what that means is that as customers add or remove networks to their tenants, we can add them with no downtime, no required router reboots. And so that makes use of the Nova interface attach and detachment calls. So what happens is at configuration time in the state machine, there's actually a bit of code that asks, well router you're alive and I can reach you. What interfaces do you have and do they match what I think you should have? And in the circumstance where they don't, well that means that we need to hot attach a network or hot detach a network. So we do so and then we have a process where effectively we wait for Nova in the background to attach that interface and for it to show up on the live service VM. At that point we continue onwards with our configuration process. So I think you mentioned this is one of the things that BSD didn't do for us. BSD, OpenBSD has purported support for hot plugging. The problem is that the device drivers also need to support that and none of the ethernet drivers actually support it. So that was interesting. We could not get it working reliably with OpenBSD in a virtualized environment. So yeah, this was a huge win by moving to Linux. And I think that and some of the other stuff that you mentioned surrounding performance was part of the reason for our move. So another interesting feature. You've got this automated system that is managing these service VMs in the background and it behaves pretty well. Largely you don't have to care that it's working. But sometimes things go wrong. So you want to be able to track what's going on when things are failing. So the rug has an interface, it's a CLI which gives you insight into the state of all of these service VMs within your entire cluster. Excuse me, other states. And you can sort of see which ones are sort of in an error state. So if for instance the rug tries to boot a VM, maybe it fails and it retries a configurable number of times. Eventually what it will do is it will back off and it will say, okay well I just can't boot this router. Maybe Nova is having an issue, a hypervisor is down. Maybe there's a bug in the code that somehow is preventing the VM from coming up and being configured. Probably not, there's never a bug in the code. No, no bug's in the code. So this is the sort of thing that saves you from overwhelming Nova and just continually trying to boot things when they just will boot. We had a brief period where we had reboot loops as a problem and that got solved pretty quickly. You don't want that happening knocking over Neutron and Nova by just constantly rebooting a VM. Or a thousand of them in this case. So another interesting thing that the rug does for you. John mentioned that we use NVP. So NVP by default. NSX now, rebrand. NSX, yeah. I'm used to calling it NVP. But so they have this feature where for the Neutron routers is a thread I think that monitors the state of the router and then updates the database periodically. So for our implementation we actually have that disabled and the rug itself actually manages that based on the state of the state machine. So as for each tenant the rug is sort of monitoring the position in the state machine of each router. It's actually calling out to a Neutron API and saying, okay, here is the state of this router. It's currently in build state because I'm building it. That's nice if a customer actually wants to be able to use the APIs or go into Horizon and say, hey, what's up, what's up with my router? So they can actually go in and they can see, oh, my router is, I've just signed up. It looks like my router is still in the process of being built. So that's sort of a high level bit of detail about how a con actually is implemented and how it works. So let's talk about how we actually run this in production and what it means in practice. So I mentioned earlier that we have a CI process where we use VWI and we build our service VMs. We have this code on GitHub internally on our Jenkins CI. We have a process where we monitor the GitHub repo and anytime we pull in a pull request and merge it we basically, we build a new VWI image. We can gate against those and test them. If we're satisfied with them, we upload them into Glance so that they can be used. First in our staging environment then in production, but yeah, either one. Ideally, yeah. No, sometimes straight to the production, right? So once you've got this image in Glance, there's a configuration option for the rug where you basically tell it the UUID of which image that you want to use. And so from there, the rug does what it does. It actively monitors the tenants, looks for missing ones, creates configures and keeps them alive. So the rug also has a CLI called rug CTL, which we can use for sort of managing and getting insight into the tenants. So there's a handful of commands that we care about, but I'm just gonna go over a couple of the really important ones. Rug CTL browse is an interactive interface for getting a list of the routers, determining what state they're in, whether they're building. It shows details about the actual Nova VM so that you can see when it was created, what image it's using. You can sort of page through these on a case-by-case basis. You can say, well, this one is misbehaving. The customer's reported issues and there's something weird. Why don't we go ahead and restart it and see if that fixes things. Rug CTL debug is also a really useful one for us for development purposes. So you can imagine that in an environment where you're spinning up all these VMs, you're managing state, things are changing in your restarting services, you're trying to debug something that's going on with one of these and the rug is managing it for you. There's a pretty good chance that while you're working on it, it's gonna cut you off at the knees. Before we had this, it was very, very frustrating to work on this because you would go in and investigate and look at a log file and then suddenly your SSH connection is gone and it's because the rug destroyed your VM. So this is a mechanism for basically saying, okay, I'm going to take a look at this VM for a short period. Go ahead and just don't work on it and then at a later time, once you're happy, you can say, all right, it's yours again. Handle it for me. And then finally, there's a command for manually rebuilding. So we actually use this for some of our testing. Periodically as we make changes and we wanna stage them or sometimes we have select customers who will say, you know, you told us about this thing that you wanted or we fixed this bug and do you wanna be a first adopter and try it? So this allows us to on a tenant by tenant basis, basically say, well, here's the special image that we've built that's beta. Go ahead and reload it for this individual tenant so that they can play with it and we can sort of do some testing. We also use this kind of framework in order to do rolling upgrades of tenant routers as well so that we don't, you know, DDoS Nova by basically saying, do all the routers right now, please. It just, you know, we wanna do them a little bit at a time and kind of roll them through. But yeah, rug CTL is great. Someone asked me the other day if there was a user interface and I said no, not yet, but that would be a pretty cool thing to add to Horizon for admins. So I think I'm gonna hand it back to John for a little bit of a retro. Thanks, Ryan. That was really good deep dive. So let's do a retrospective here about some of the problems we faced when we went through this process with the conda. So remember I, you know, and I, my discussion, we started this project a couple of years ago and at the time there was no such thing as IPv6 support in Neutron. So we had to make some modifications ourselves and as many of you know, we're still in the process with Neutron of getting IPv6 fully working and it's really getting, they're making great progress but we're kind of early adopters and so we had to go through some of that pain. We still have some differences in deltas between our version of Neutron that we have to run and mainline Neutron. So we're working on getting that all upstream, moving to everything to make it more vanilla and I think probably the biggest challenge that we faced is the fact that state machines are hard and distributed processing. It's a really difficult problem. The appliance itself is really pretty straightforward. You know, having a service VM and wiring it up to your layer two and to the tenant itself is pretty easy to do. You can do it manually and you can automate that pretty well but if you wanna manage these things at scale and push out configurations, monitor them for their health and make sure everything transitions through the right states without getting into reboot loops and DDoSing, Nova and Neutron, you really have to have a very sophisticated system and the rug took a lot of development time so that was a really big challenge. Another big lesson that we learned is the best way to achieve stability as quickly as possible is to just, you know, automated in an automated fashion beat the hell out of it, right? We spent some time spinning up thousands and thousands of VMs a day and destroying them in an automated fashion, monitoring for errors, creating networks, destroying them, just absolutely destroying and demolishing the cloud to really exercise the rug and exercise a conda and that turned out to be the biggest win by far so we're big believers in that and a conda's gone through a lot of hardening as a result so we're really happy with where it is and another big challenge is as a small team, you know, keeping track of OpenStack as it's exploded with, you know, thousands of contributors and hundreds of companies involved is a difficult task and keeping up with mainline OpenStack is not always easy to do but we're excited about that and especially excited because of the future so earlier I mentioned how DreamHost incubated Ceph, the technology and then created a company called Ink Tank and really helped push it forward into the community and make it an awesome thing that we're all using and that turned out really well it worked well for the Ceph community because additional features, capabilities, bug fixes and support, it worked well for customers, people who are consuming Ceph because they can now get support and could get help making it run and scale so it was really great for everyone involved, contributors, community and so on so obviously you can see the writing on the wall here we've actually launched Aconda as a separate business we've spun it out and got a CEO on board who's here in the room, his name is Henrik, wave Henrik we're really excited about this and it's kind of like, you know, that's why I use the little baby icon for Aconda it's our little baby, we're setting it free and we want everyone else to use it as well we really want the community to take advantage of it as an open source project, right we're not taking this thing closed source it's a real open source project, a community that we want to start building so we'd love for you to get involved to help us build kind of the future here and some of the things that we have on the roadmap as I mentioned earlier, additional services, right these are just Linux service VMs a lot of the NFV talk right now that's going on is talking about all the different functions you can virtualize, network services that you can run in these little Linux VMs and wire them into your networks kind of the sky's the limit here but we're going to start with load balancing and firewall because we feel like integrated with Neutron's APIs that would be a really good spot for us, Dreamhost so as a customer of Aconda we're going to ask for that and help contribute to that put the code out in open source for everybody and we also know that not everyone in the world is going to be running VMware NSX and that's fine you know, we like it a lot we think it works really well for our L2 have a good relationship with them but we also know that other people might want something so we're going to be working on other L2 backends working with the open daylight community working with just going down to physical talked a little bit about VXLAN and some other options there so we'd love to get people involved on that front and then we want to add some kind of enterprise features to the rug itself some more HA kind of operation modes scale out we've also talked about taking advantage of the hot plugging features that we've worked on now to do things like having a pool of pre-booted unconfigured routers or appliances that we can then hot plug into the customer networks to reduce the time to availability for new customers or for additional services we've done some early testing on that and that works really well too so we're really excited go check out the code go to aconda.io to get more information it's linked to the Dreamhost GitHub for it eventually that'll move over to Aconda and both Dreamhost and Aconda are hiring so if you're interested in that as well let me know and wherever you are if you want to get involved in the project please do get in touch we are, you know, it's all under Apache 2 license bring your code, bring your bugs, bring your ideas, we love it so and that's it, thank you very much I think we've got about three or four minutes for questions maybe so if you have a question find your way to a microphone we've got one over here on your left I'm wondering how you implement the floating IPs do you do the one-to-one NATs or are you just routing those directly in can you talk a little bit about those details yeah, so for the floating IPs we do one-to-one like source and destination at NATs with IP tables even on the IPv6 side so we don't really have many people that do v6 floating IPs yet, right this is the thing we want to do right now the way that works and this is an area of improvement every VM gets a v6 address, it just gets one and you can't assign additional ones so obviously if you want to do things like failover using a floating IP on v6 you can't do that yet but we are going to work on that for sure and if I understand this right I mean this is basically an alternative to Neutron is that accurate? no, it absolutely is not it integrates cleanly with Neutron so Neutron has a pluggable backend as you know and as requests come into Neutron that's the API that is exposed to the world that's the API that people use to assign floating IPs to do anything and we just listen to the messages that come out of Neutron and then make things so, right we make it happen on the service VM so you're an implementation of Neutron routers is a better way to say it and other services and features we integrate with Neutron I think that would be the best way to put it thanks so these service VMs are visible to the tenants or is that hidden from them? so they are not they are actually they are under ownership of the Neutron service tenant so that way customers don't have to worry about that for quota and they are so they're not going to shoot themselves in the foot now they can interact with the service VMs in the sense that they can issue Nova or Neutron requests, right and those Neutron requests will get consumed by the rug and then cause things to happen with a service VM and they can also see their router state in horizon or through Neutron through the API so it's not completely out of their reach but the API itself listens on a management network that the tenant does not have access to so did you have to change any horizon or anything to make this VMs show up in that network? no changes to horizon we do have some changes in both Nova and Neutron we're trying to get as much of that upstream as possible and try to get away from having to have custom versions of that so that's kind of part of the next couple months of the development's gonna be upstreaming everything, all the things yeah and initially this started out as just like for us a big, big fork of quantum for the changes and over time, like you said we've slowly just been bringing things in so the repository might still be called quantum so for a very long time it was called quantum we'll have to make sure we talk to someone in the know on that, make sure we don't get sued let's see, I don't know who is next we'll go with you I just had two quick questions where does the rug run and like do you have any scalability information when you do DHCP, is it Slack or sorry, when you do V6 is it Slack or DHCP V6? okay, so second one first, Slack first one, so the rug runs inside of what we call our cockpit so it runs kind of alongside the other open stack services and in terms of scalability we are not even breaking a sweat right now and but we do think that there is opportunity from our scale out, right now it's based on multiprocessing and multi-threading so it can scale up a lot on a single node and we have failover but we don't have full on HA or scale out horizontal yet so that's in progress in the plans and break a sweat is thousands of service VMs? thousands and thousands, yes so one interesting thing is that actually in terms of scalability and performance issues so the rug itself, it's really just multi-processed Python code and much like Horizon I guess it's only going to be as slow as the endpoints that you talk to the real problem is not the rug I'll just put it that way we tend to knock over Nova Neutron yes if I understand correctly the data plane that you've added is that you've got an extra hop now to the service VM how does that affect performance for your tenants? I actually don't know if I have a good answer for that the throughput's really good that's one thing I can say in terms of how it would be versus other options I don't know if I have a good answer maybe we can talk afterwards thank you so you mentioned that you're planning to upstream most of them but there's an effort with Neutron to actually get service VM as an incubation project sure so I guess we're going to participate and roll this out yeah so big difference between Tacker and Acondas that Acondas working so we'd love to work with Tacker obviously but it's an early stage kind of thing so we wanted to get out there, get it upstream or get it open source and then engage and talk and see if we can work together I mean obviously it'd be good to be you know the same thing so yeah definitely interested obviously we want to go the way the community goes perfect it's 240 and we're done thanks guys


This army presents the Big Picture, an official report produced for the armed forces and the American people. This is the story of Camp Century, the city under ice. It was in May 1959, after more than a year of preparation, that a small party of army engineers conducted the final search to select a site for Camp Century. Listen now to the voice of Captain Tom Evans, the young officer who was in charge of the construction of the camp. This was the day we really got underway. Colonel Kirkering, commanding officer of the United States Army Polar Research and Development Center, was with me when we made the final reconnaissance. We needed a flat surface, a level with less than one degree of slope. This would minimize construction problems by enabling us to keep all of our tunnels on the same level. We finally picked this plateau, a smooth white plain of ice for as far as you could see. This was the closest location to Tully, our supply base, which would not be affected by the summer thaw. That first day we set out flags, marking the boundaries of the camp. This is rugged country. Nothing lived on the ice cap. Not even seal or caribou survived in this climate. Our job was to cross 150 miles of ice, much of it split by crevasses, and then build a city under the ice, experimenting with new concepts of polar construction. It was several weeks later at a point where the ice cap sloped down to a narrow strip of barren land along the coast that our supplies began rolling in by truck for transfer to sleds. To make this transfer possible, we'd had to build a three-mile road up onto the edge of the ice cap. We brought in everything this way. Construction materials, steel arches, clothing, nails, steel beams, prefabricated houses, lumber, food, even ice cream. In the months it took to build Camp Century, more than 6,000 tons of supplies were used. Even the vehicles we used at the site had to be transported over the ice on big bobsleds. We called these convoys of 10 and 20-ton sleds heavy swings. Crawling up the ice cap at approximately 2 miles an hour, a heavy swing would reach the camp in about 70 hours if everything went well. We used wooden kaboose-like trailers, wanigans, to house members of the construction crews for the three-day trip. Muckluck, a three-month-old Eskimo sled dog, went along as camp mascot strictly against regulations. Caterpillar tractors with extra-wide treads pulled the heavy swings. Each tractor could pull from 50 to 100 tons. Finally, like a wagon train in the Old West, the first heavy swing got underway. At the same time, we used another type of smaller vehicle to transport an advanced party. These pole cats would average 10 miles an hour and make the trip a little more than half a day. A convoy of pole cats, each section carrying six men, was called a light swing. We also used light aircraft. Throughout the operation, these flights brought in key personnel, special cargoes and mail. We couldn't forget anything. This was a country in which to turn around and go back. A compass was useless this close to the pole. Instead, our convoys followed a series of trail markings. Traveling in a wanigan was a long way from the early tractor trains of the 30s with sourdough biscuits and warmed up bean. From the days spent loading the heavy swing, the men's faces were already deeply sunburned. During the trip, in shifts, half the men rode and half slept. Navy-type bunks were used for sleeping if you could sleep in the 24-hour sunlight. First to arrive at the surface work camp were the aircraft. A few hours later, the pole cats pulled in. For the next several months, this primitive scene of crowded James Way Arctic huts with outdoor latrines was our home.  All together, I had four other officers and a hand-picked group of 11 non-commissioned officers to help supervise the military construction crew of Camp Century. Plans for the camp had been developed months in advance. The basic concept was simple. A system of 23 trenches would be dug into the ice cap and then covered with steel arches and snow. Branching off the main communication trench would be a series of lateral trenches, housing complete research, laboratory and test facilities, modern living quarters and recreation areas, and a complex of support facilities. Since transporting great quantities of diesel fuel over vast arctic wastes was impractical, we would install a nuclear power plant. We got to work immediately cutting trenches. This snow-milling machine, the Peter Plough, was our pride and joy. Manufactured in Switzerland, it could handle up to 1200 cubic yards of snow an hour. Designed to clear roads in the Alps, it was ideal for our purpose being capable of making extremely precise cuts. It was usually operated by two men, one controlling the machine's horizontal movement, the other controlling its vertical movement and speed. When a trench was several feet deep, planks were put down on the shoulders of the cut. Later on, these planks would be used to support the steel arch roof which would cover the trench. Camp Century was starting to grow, and so was Muckluck. We used three Peter Ploughs to cut all the different trenches we needed. By making a series of undercuts, the width of most of the lateral trenches was greater at the bottom than at the top. This cut down on the amount of roofing material required. Before long, the first roofs began to go into place. Constructed of overlapping steel arches, these roofs could be put up very quickly. By this time, we had a crew working in a snow quarry cutting large bricks of snow. In this way, we made maximum use of the materials available at the site. Somehow, Muckluck seemed to be everywhere, always making himself useful. When a roof of steel arches was in place, it was covered with snow. Because it had been milled, this snow would harden into an extremely durable surface. Inside each tunnel, at the end of joining the main communication tunnel, passages were cut through. Not all the excavation could be done by machine. The shovel was still a very useful tool. Next, work began on foundations for the prefabricated buildings that would be placed within the tunnels. Leveling the floor was very important to provide a good bearing for the foundations and prevent any building from settling unevenly. This was cold work. The temperature within these tunnels sometimes went to 20 degrees below zero. And this was summer. Prefabricated sections were delivered by forklift. The non-conductive wood in the air insulation barrier below it protected both the building from the cold of the ice floor and the ice floor from the warmth of the building. Every prefab that went into Camp Century had been pre-erected, tested, and then shipped to us as a unit. Every clip, every doorknob, every light switch came in a single shipment. In this way, we knew there would be no delays caused by missing parts. This is a standard T5 engineer arctic building designed for cold weather use. Composed of plywood insulation panels, these buildings would provide space for comfortable working and living under the ice. Since every unit had been checked out in advance, more crews could put up one of these buildings in less than a day. As soon as the shell was completed, crews began to wire the buildings for interim power provided by diesel generators. As the major interior work within each tunnel was completed, the entranceway was blocked up with bricks of snow. It took about two days to build one of these walls. Once in place, these bricks would bond together into a solid wall, and only a small entranceway would be left. We then used a bulldozer to push loose snow into the doorway of the tunnel to complete the seat. Later, an escape hatch would be placed at the end of a small wooden form for an emergency exit. When it was completed, the entrance was weatherproof and serviceable. Throughout the long period of construction, within the primitive facilities of the work camp, the men solved the everyday problems of working and living as best they could. Meanwhile, work had begun on the four nuclear trenches. These were the widest and deepest trenches and did not use the undercutting principle. On this cut, we used three plows simultaneously, two plows throwing up snow from below, the third cutting a spoil trench up above to prevent loose snow from sliding back into the cut. To avoid melting caused by the sun, much of this work was done at night. These scenes were filmed at 2 a.m. Until the trench was covered, there was always a threat that the 40-foot arches would collapse a shoulder already weakened by the 24-hour-a-day Arctic sunlight. The faster the roof went up, the better. The frame for the reactor building was made of steel beams. Despite the cold and the constant winds, my construction workers climbed like monkeys over the scaffolding and rode the beams into place. At this same time, within the tunnels already completed, we were installing piping for water and electricity. Heavy insulation material was wrapped around every pipe to protect against the extreme cold. A copper heating element inside the insulation kept water lines from freezing. Flexible sewage lines also had to be run through the camp. At this time, to keep on schedule, we were using 12 and sometimes 14-hour shifts. For like any modern city, camp century required a complex of interconnecting corridors carrying a maze of piping of all sizes and shapes. One of our proudest achievements was our solution of the water problem. A steam hose with a special drilling nozzle was used to melt a hole 3.5 feet in diameter, 120 feet down into the ice cap, until a pool of water formed which did not drain off. This pool provided 10,000 gallons of fresh water daily. Throughout the camp, an extensive electrical system was now installed. For electrical heating would not only be clean, but it would also reduce the threat of fire. And fire was the worst hazard under the ice. From the very beginning, we had to take precautions against fire or a storm closing the ramps, or any other disaster which might block the regular entrances to the camp. 16 of these escape hatches were strategically located throughout the various tunnels. In their off-duty hours, the men did what they could to amuse themselves with the recreational opportunities at hand. Bronco busting was one favorite pastime. By this time, muck luck was almost full-grown. Early July, most of the heavy construction work on the tunnels was completed. Throughout this operation, it was a steady stream of heavy swings moving back and forth across the ice. More than any other single factor that made it possible for us to complete camp-century on schedule. To service our many vehicles, a maintenance shop was constructed closer to the surface, both as a repair shop and as a garage. For the sub-zero temperatures meant equipment had to be kept warm. Otherwise, engines wouldn't start, lubricating oil solidified, and electrical connections froze. It was at this time that the marine fiddler arrived at Tully with the nuclear power plant, designed for air transportability but transported by sea to reduce costs. The nuclear plant was the last major phase of our operation and the most difficult. This unit, for example, part of a vapor container, weighed more than 21 tons. Awkward to handle and with high centers of gravity, these packages were delivered to the ice cap over a road built specifically for their transport. More than 400 tons of piping and machinery arrived in this one shipment. Since the Arctic cold makes metal very brittle, each unit had to be handled with great care. The vapor container, the largest single item in the power plant, was carried on a special flat-bottom sled built expressly for its transport. Everything seemed fine the morning the heavy swing moved out, but unfortunately it was only a few hours later that one of the worst storms of the season grew up. To complete preparations to receive the nuclear plant, my crews bundled up and kept on working. The opening and the roof of the main nuclear trench now had to be closed quickly before the trench began filling with snow. Despite the storm, the heavy swing was still moving. My crews kept working. It was the only way we could be ready. Just as the swing arrived at the camp, the storm led up and tarred. Work began immediately unloading the shipment in preparation for its replacement. Covers were removed, crates opened. Boxes of piping and wiring, each item carefully labeled, were opened so that each unit would be available when needed. Major components shipped in pieces because of weight limitations were reassembled before being moved into the trenches. The condenser, 15 tons of steel, was one of the first units to be moved into the tunnel prepared to house it. When the condenser was slowly winched forward, small-track rollers supported its entire weight. Next, still mounted on its special sled, the vapor container was eased down the ramp by three tractors, one in front pulling and two in back to keep it from slipping. To bear the weight of the vapor container, the reactor building was constructed around a framework of steel beams. The floor was of heavy planking mounted on other steel beams. We had to use hand-rigging methods, the best we could do under the confined conditions to put the nuclear equipment in place. The power plant consisted of four basic elements, a nuclear heat source, equipment that would convert the heat energy into electrical energy and a system to dispose of excess heat, all regulated by an extensive network of instruments and controls. The last buildings to be assembled were those that would contain the nuclear sections. These shells were built around the nuclear system equipment only after every major component had been put in place. The next phase was to be the activation of the nuclear power plant. Wearing the white safety hat is Captain Jim Barnett in charge of this operation who will tell you about this critical phase. We took every precaution in the book and some that weren't there to make sure this would work right the first time. When the entire system had been carefully tested, it was put into operation. We were then ready to begin loading the reactor core. One by one the fuel elements were removed from the barrels in which they'd been shipped, carefully separated from one another. Each of these bars containing approximately 500 grams of uranium-235 was then unwrapped, inspected and wiped clean of any dust. Crewmen wearing protective clothing began to load the fuel elements into a fuel storage tank. This preliminary test proved that the fuel elements, when assembled, would not go active prematurely. After each element was in place, instruments were read and an evaluation of reactivity was made and reported over loudspeakers. The crewmen were protected by a shield of approximately 8 feet of water as they lowered the fuel elements into the fuel storage tank. Later, each of these steel and uranium bars would be transferred underwater to the nearby reactor core. Every step of the testing was meticulously monitored and regular announcements made to the workers assigned to the loading crew. 35 content of the assembled core is 13.376 kilograms. Coefficient of reactivity, 0.935. The assembly is still subcritical. When all preliminary tests were completed, we began to transfer the fuel elements one by one and started loading the reactor core. As each fuel element went into place, the count rate of neutrons released gradually increased. Within the core, to prevent the reactor from inadvertently going critical, control rods were in place. This gradual activation of the pile took almost nine hours. In this tense atmosphere, we changed crews twice. Above us, it was dark and miserable. With the approach of winter, the sun was preparing to set for the year. Finally, our meters reported a significant increase of reactivity. The whole cap was standing by, waiting, tense. By the ninth hour, the last fuel element had gone into place. A plot showed the location of every bar. Then the control rods were gradually withdrawn until the reactor went critical at 6.52 a.m. Within the next few weeks, the final touches were put to camp century. Today, powered by its nuclear reactor, this unique installation is a completely modern community deep under the ice. This is a far cry from the primitive James Way huts of the work camp where three showers served 250 men. Here, there are showers for all and facilities for every modern convenience. Among the many sophisticated facilities at camp century is the dispensary, complete in every detail. For while the remote research community is isolated by 150 miles of ice and snow, its medical capabilities can cope with almost any emergency. It also has a small chapel for regular religious services. And it boasts the largest deep freeze in the world. Here is enough food to feed the camp for several months. Everything from steak to fruit salad. The modern spacious kitchens provide a well-balanced and appetizing menu. To satisfy the enormous appetites that working in this climate produces means extra rations, but there's always more than enough. Except for the fact that they have no windows, the men of camp century live exactly as do other soldiers. The quarters are modern, spacious, comfortable, and are not lacking in any detail. Today, camp century is being operated as a year-round Arctic Research Center. The men who built the camp have long since been replaced by military and civilian scientists from the Polar Research and Development Program. As part of man's efforts to probe deeper and deeper into the secrets of the universe, an elaborate program of tests and experiments is being carried out. At this very moment, somewhere, men from camp century are at work, within the city itself or out on the ice cap. Only mock-lock remains from the original contingent. This is the story of camp century, of the Army engineers who carved out the underground city, of the many other men of the United States Army who made this project possible, and of man's never-ceasing quest for knowledge. The big picture is an official report for the armed forces and the American people, produced by the Army Pictorial Center, presented by the Department of the Army in cooperation with this station.


Hello and welcome to the session. The given question says the 7th term of an AP is 32 and the 13th term is 62, find the AP. Let's begin with the solution. So here we are given that the 7th term which is denoted by A7 is 32 and the 13th term is equal to 62. Now An is equal to A plus N minus 1 into D where A is the first term and N is the nth term and D is the common difference. So let us assume that the first term of the AP be A and let the common difference of the AP be D. So a required AP will be of the form, the first term will be A, second will be A plus D, third will be A plus 2D, fourth will be A plus 3D and so on with this term be A1, second term be A2, third term be A3, fourth term be A4 and so on. Now we are given that the 7th term of AP is 32. So by using this formula we have A plus 6D is equal to 32 and the 13th term is 62. So this implies A plus 12D is equal to 62. Let this be equation number 1 and this be equation number 2. Now let us subtract the second equation from the first one to get the value of D. We get here minus 6D is equal to minus 30 or D is equal to 5. Now substituting the value of D which is equal to 5, an equation number 1 to get the value of A we have A plus 6 into 5 is equal to 32 or we have A is equal to 32 minus 30 which is equal to 2. Therefore A is equal to 2 and D is equal to 5. Therefore the required AP, first term is A that is 2, second term is A plus D so 2 plus 5 is 7, third term is A plus 2D so we have 2 plus 2 into 5 which gives 12 then we have A plus 3D which gives 17 and so on. So this is the answer to the question. This all worked. Hope you understood it well. Bye and take care.


Everybody forced here ripping 2023 tops Cosmic Chrome baseball hobby six box number 16 picker team style. We've got Alex M Cardinals, Andrew S Giants, Anthony K Royals, Bob C Marlins, Brian L Cubs, Edward P Phillies, Frank V. Sorry, Frank Y has the Mets, George S with the Guardians, J R W Mariners, J H Twins, Joe H Orioles, Johnny A Nationals, Jordan N Padres, Jorge M with the Dodgers, Keith J Astros, Kendall M A's Larry F Angels, Lucas P Rockies, Mary Bell with the Brewers, Matthew B Tigers, Michael has the Yankees and the Pirates, Ray Diamondbacks, Robert P Rangers, Roger S White Sox, Ryan M Braves, Scott T Reyes, Steve C Red Sox, Todd W Reds and Zach has the Blue J's. Good luck everybody. Let's do it. Come on second half of the case. Help us out here. We've got a pretty crazy daytime. We've hit some monsters today. Ah, real monsters is what I say. That's that's that's what happens. Planetary Pursuit Mercury, Masatake Yoshida. I miss. Boom. Boom. What happened? Masatake Yoshida Mercury. Jake just wants to see your reign. It's real bad. Awesome Yoshida. There's a ton of extraterrestrial talents. Roll a die here. So we'll go one, two, three, four, five, six and all the triples. Um unless there's a majority. So unless somebody has the other two or whichever it may be, you know what I mean? Three. We'll go middle on the triples unless majority for every single one of the triples. Pretty sure that's earth. Do you do you live on that planet that they showed there Cameron? I'm worried about you now. Fracture Yastremski. Let me get the Yoshida. There we go. Congrats Red Sox. Akunya. You guys ever seen that? How does it go Jake? Yes. That's my girlfriend to go to the Red Sox game with me. And I to 99 Stanton Yankees on the blue. Vaughn probably knows. I took my girlfriend to the to the Red Sox game. So, I can tell her Yoshida won for me or whatever it is. And then I told her she's Masatake. I call her Masatake. She's Yoshida won for me. Nucleus Togliar, Rookie for the rise. Got Rookie refractor, Almond for the Dodgers. Yeah, we're messing. That's a gist of it though. It's amazing. Yeah Cameron, you should you should maybe check it out, huh? Stars in the Night is Alvarez for the Mets. Weird box. Two stars in the night already. Carrero and bow. I still want to see it parallel on one of those Star Clusters. Michael Harris, the seconds. Do we have it here? No. You've been around for every single galaxy I've ripped, actually. My galaxy, sorry. Cosmic. Those are easy to mix up. Top's Galaxy Chrome. Top's Cosmic Chrome. Triple for the Padres. Aqua Equinox to 199. Is Shane McClanahan raised? Cy Young Shane? Not anymore. He will, he will not win. That's a fact. How do you know? No, we're we're not running early. Refractor, Nymoc for the Mets. We're on daytime schedule right now. This is number 16. Yeah, this is Cosmic Chrome. Six-Box Happy. This is number 16. Seeker and Jung. Uh yeah, 17 should still be a 720. Wherever the scheduled time is. Orange is a Rookie Edward Julian. Congrats to the twins. Good Magnus one. You got twins. 12 with 25. That is great. First rookies. Enwar. Jordan Walker. Altman. Card's far out, man. Fractor Redetmer's Angels. Stars of the Night. Bryce Harper for the Fills. Aqua Equinox to 199. Bregman Astros. Are you able to set up yet or is that still going? You can use the laptop in the front shop area. 75 is Lindor for the Mets. Got any old crews? No. Yep, three run. Tied up now, right? Nucleus Rookie, Mazataki Yoshida. There you go, Red Sox. Nice card. Refractor, Rookie Groshan's Marlins. That's on nine. No way. With two outs. That's huge. Yankees are saved. Yankees are saved. Oswaldo Cabrera, Rookie Auto to 75 for the Yankees. Persony. You didn't have 20 hits.  Who'd have thought? Not me. They sell the Yankees in breaks now. All right. Don't want extras. You know, Randy's the first player in our history to hit three straight seasons of 2020. Rashida, Beatty, Ruchman, and Gunner. Gunna. Kevin Cash. I was in her canario getting called up now too. Jordan Walker, extra threshold talent. So that's Maricio, Wells, maybe Dominguez. No, Dominguez is confirmed. Oh, it's confirmed? Yeah, he's on his way. Oh yeah, that's right. I saw that earlier. Sorry, whatever happened earlier before I broke, I it's not gonna register until later.  He's on a plane of flight. Wherever they're going, I think, I think he's probably wherever. He sat next to him and he had his glove out and he was like, he really has. Can I see the orange?  And Dominguez was like, yeah, I play, or he's like, he laughs, he's like, I play. The guy's like, are you any good? And he's like, I'm Martian. I'm good. I'm Martian. Interesting. What a thing to say to people. Shout out, Tony. It's gonna be the next. That guy back there is not real. It's gonna be one of those. Call himself Martian. Austin Riley launched into orbit. It's got Renfro and Harrison Baker. You see them gardeners? They just took what the angle was. Well, I saw Renfro was playing the night after he got waved. Nucleus Cabrera for the Tigers. Because it doesn't go through until it's gotten weird. I'm not tackling on this team anymore. Launch and orbit Alvarez. Did I tell you the same about Merlin? Change the combos. You see whatever's in the break description for like Merlin? If you have any going forward. I forgot if I sent that or not. Aqua rookie will Benson to 199 for the Guardians. Guardians, right? Or Reds. Oh, Reds. Sorry, Reds. He was a Guardian. That's what that's just throwing me off. Rather the green. Just like Wade Miley. Wade Miley is the new Edmund Jackson. Kind of Henderson right here. Factor Michael Harris, a second for Atlanta. The Sheffield. Josh Jung. Did you say hello before? I just started making noises. I didn't print. My printer does that sometimes too. I'll be like really quiet. It's not my computer concentrated on something. It does like a self-like cleaning. Something like, Pajero, Pajero. I'm like, what? Scares me. It's 99 Nate Lowe for the Rangers. Does he go by Nathaniel? Blue Refractor to 99 there. Triple Phillies. Come on Cosby. We need more. We need more juice. Rikki Refractor. James Outman. Dodgers. Mervis. Waters. Asad. Stars of the Night of Masatake Yoshida. Red Sox. Oh, and Bo. Alvarez. Extra-trestral talent. It's like I was saying everybody. Mosaic. Basketball. Tomorrow. Daytime. As well as Donner's Sleeve Football. Both released tomorrow. It'll be a good day. Lot of releases this week. We've got Star Wars breaks this weekend too. If you haven't seen those, check those out. Tani launching to orbit. Corbin Carrol. O'Harris. Piguero. Alvarez. Extra-trestral talent. Pablo Lopez on the nucleus for the twins. Carrol, Moreno, and Thomas. Launching to orbit. Vlad. Down to your form. That means he's gonna go ham next year. Drew Waters. Rikki to 199 for the Royals. They're still really good without him mashing. Bobby Wittz. Groshan's Nucleus is an Ahmed Rosario for the Guardians. Refractor, Glaber, Torres, Yankees. Josh Zhang. Gunner Henderson. Lang. Lang? Yep. Got the Grom. Unbelievable. Torquoff, I'll see it. Planetary Pursuit, the Sun. Francisco Alvarez for the Mets. Very nice card for the Mets on the short print. Casas. Refractor, Corey Seeger, Rangers. I would say unless it's like... If you don't look real quick. I mean we can see... Ruchman. Let's see, let's see. I think testing. Testing, testing, testing. That part of the show is just so unnecessary too. That's why it's so awesome. It doesn't add any...  Love it. Gotcha. Sounds good. Adminable Valdez, Blue Rookie to 99 for the Red Sox. Senga on the Extraterrestrial Talents. Brad Bady, Rookie Nucleus for the Mets. Refractor is Iohini Osora's Guardians. Not Guardians. There's Mariners, Iohini Osora's. Is this it? Yeah, yeah, that would be for sure. Ruchman. The Vets are probably going to have to go outside of Otani, I think. Got Walker. Henderson. Right. It's going to be one of those things where like the more rare planets go for like crazy, but like the lower ones are like respectable, like so-so. Buxton. Kodai Senga. Come on. J-Rod launch in Orbitz, Stowers. Probably gots pristine two-box Rand divisions after this. Got Kyle tonight, everybody. Thomas Carroll, Moreno. Gold coming up and it is a C.J. Abrams Nationals. Nice gold. It's a 50. Carol Extraterrestrial Talents. Ron Bady. Refractor, Abreu for the Astros. Yoshida, D.L. Hall. Pena with J-Rod and McClane. My Extraterrestrial Talents. Come on now. More SSPs. More SSPs. C.J. Crone, Nucleus, Rockies and Griffie. Last one. Box six. Yoshida Extraterrestrial Talents. Praza, Cabrera Volpe. Julian. Devers launch into Orbit. We have low number of something here. Orange launched into Orbit. Kyle Schwerber. That's pretty cool for the Phillies. Number 19 of 25. There we go. That's the number. What's that? That guy knows how to launch into Orbit. Yeah. It's like 190, but he does make contact. That's pretty far. Refractor, Alejandro Kirk, Blue Jays. 10th inning. Here we go. Mervis, Drew Waters. Rookie, Riley Greene, Stella Nova, Tigers. Congrats, Tigers. Me as well, but I wouldn't even follow her. Nucleus, Starling Marte, Ordemettes. Anything. Nice. A Riley Greene Rookie. Aqua now to 199. Yeah. He's going to be pulling Riley Greene. That's for sure. 7 of 199. There you go, Tigers. That's why I just crushed it. I didn't realize I was telling Nova's we're pretty high right now in eBay. That's kind of cool. Refractor, Yastremsky for the Giants. Yeah, seriously. Yeah, Yoshida. Yeah, you know all about that, Brian. You know all about that. You have the Super Yashra. Did he? Yep. Wow. Cheyrod, Stars of the Night. Crazy. All right. Let's do a recap. Kind of a quiet overall case. Second half was better than the first half. We just got one break left, everybody. All right. So we had the sun short print of Alvarez for the Mets. Aqua to 199. Bregman, McClanahan, Drew Waters, Will Benson, Riley Greene, Blue to 99 in the Faniel low. Giancarlo Stanton at Manuel Valdes to 75. Green, Lindor, Gold to 50 Abrams. Orange launching to orbit at 25 is Kyle Schorberfili's Green Rookie Otto to 75. Cabrera Yankees. Riley Greene, Stella Nova, Rookie Short Print for the Tigers. I think so too, Brian. He's very underrated right now as well. He's hitting super well and he just, people aren't paying attention because he's a Tiger. He was also a very highly rated prospect before he got hurt right before his rookie year and it put them back into like everyone got a bad taste in their mouth about the Tigers. So he's really freaking good. He's also a good defender. We had Planetary Pursuit Mercury, Masatake Yoshida, Red Sox and an Orange Rookie, Edward Julian for the Twins. Good stuff. Thanks again, everybody. Moving on now to Pristine.


Hello, and welcome to theCUBE's presentation of Women in Tech Global Event, celebrating International Women's Day. I'm John Furrier, host of theCUBE, got a great guest, Cornelia Robinson, who's the senior manager of the Global Inclusion and Outreach programs at AWS Amazon Web Services. Cornelia, welcome to this CUBE presentation. Thank you, so happy to be here, John. So you got a very interesting background, been involved in communities, you're in outreach and inclusion, which is awesome. International Women's Day is about global celebration. What's your role at AWS? Tell us more about what you do there and we'll get into some of the background and your experiences. All right, thanks, John. So I lead a program that's called Inclusion and Outreach within AWS specifically for our global data center community. So AWS infrastructure is all over the world and we strive to make sure that in the places where we build and operate our cloud, that we're being good neighbors and also striving to be Earth's best employer. And so my role, it ultimately aligns both of those things into both inclusion and outreach. You know, one of the things that we see with the cloud is, you know, there's always the talk of democratization. And if you see what cloud has done inside the global communities, it's been interesting. You know, as regions expand, cloud computing has actually enabled kind of new things. You're seeing a lot more diversity, inclusion. Women events, for instance, in Bahrain was one we saw a lot, Asia Pacific and all around the world you're seeing a lot more community because of the opportunities around the new applications and the new use cases is creating economic but also empowering opportunities. And you've had a lot of experience in there and seeing some of these trends up close. What have you seen around this? Because this is a new thing that cloud's enabling this new revitalization inside these communities and areas. Yeah, cloud is definitely an enabler and it also enables people to scale, right? In ways that you wouldn't have been able to scale in the past. You know, with AWS it's like you flip on a switch and all of a sudden you have access to so much compute power. It's actually incredible and it's exciting to be a part of this movement. How did you get started with AWS? I guess the way that I would describe it is tech kind of found me. I have an unusual background to be in tech. So I graduated from law school and I was looking for a job and ended up in procurement. And then some years later, I got a call from AWS and I thought that it sounded like an interesting opportunity. I'd have an opportunity to build some new things and try some new things. And so I said, hey, why not? And that's how I ended up at AWS starting out in our Northern Virginia office. And then I moved to Seattle for about five years and now I'm back in the Northern Virginia area. So you're in Amazonian, true and true then. You've seen all the growth. But I think the thing about Amazon is that there's so much opportunity internally. Other people don't know that. And I'd love to get your take on what it was like moving from procurement, which probably was very structured and a good fit there to Amazon Web Services, which was at that time just growing really fast and you built a global community program. So kind of two worlds, take us through that. Yeah, you're right. Procurement and community engagement are very different in many ways, but also very similar in many ways as well. With community engagement, we were completely starting from scratch with the idea of a structured community engagement program, even though there was an element of community engagement that was happening in our infrastructure locations. So ultimately, the way that I ended up making that shift is that I was in an offsite which is a team meeting where people who have different functions come together. And we were discussing opportunities that we had to just do a better job overall because as you know, that's one thing that we're always looking at as Amazonians. It's how can we be better and show it better for our customers? We're always trying to start with our customers and work backwards to meet their needs. And so one of the things that was identified in that discussion is community engagement. We had an opportunity to be even more engaged than we already were and to do it in a structured way. And so I shot my hand up and said, I like trying things. Let me try this. And the rest is history. It's been about four years. And obviously you had to go back to documents and all that procedure. Amazon is pretty open about ideas. Is that true? Is that a true thing? Is that what it's like there? People say that they'd like to try things and then if it works, they double down on it. Is that kind of how this went down? That's exactly how it went down, John. So when I think about the process of working backwards, it's really something that never stops. And again, community engagement was all about working backwards from the needs of our customers. And in this instance, when I think about my customer, my customer is our community members. It's community members who live and work in our data center regions. And also our employees who are living and working and raising their families in those regions. What was the double down moment? When did you say, wow, this is working when you develop this program? What were some of those moments where you said, wow, this is actually working and take us through some of those progressions? Some of the moments that really stand out to me are moments where I've been in the community and I say AWS and someone says, oh, what's AWS? And then you'll hear someone else chime in and explain, oh, AWS does all of these great things in the community. So that actually happened. It was our very first AWS Girls Tech Day. We had scaled it from a small program into a global program. We went from having one in one year to having eight the next year around the world. And at this particular AWS Girls Tech Day, someone did ask that question. It was a little girl. She was standing next to her sister. And when she asked me what AWS, what AWS is, her sister looked at her and said, you don't know what AWS is? AWS does so much in our community and AWS has, I think, big space in my school and she went on and on about how much she works with our employees and how excited she is about technology. And those are those moments where you say, you know what, this is working. It's really working. That's awesome. What advice would you give people who are developing a community program because you're a pioneer, this has been a top priority for people now in all companies and all groups and all tribes, communities becoming a really important part of our fabric of society and business. People are sourcing information. They're sourcing relationships and jobs and products. They're seeing a lot of organic community. What advice would you give folks who are developing a community program? There are a few things. So for me, the biggest and most important thing is working backwards. So start with your customer. Who is your customer? It's really important to listen to them and to identify their needs. In this community engagement space, you have a lot of things being thrown at you all the time. You also have your own ideas and it's like, oh, it'd be really cool if we did this thing, but is that really what the community needs? Is that really what the community wants? So when I first started in this role, that was the most important thing and it continues to be the most important thing. I started picking up the phone, talking to people, going into a region, talking to folks who actually live and work in the community, understanding their perspectives, understanding their needs. There was a lot of discovery during that time. They were able to tell me things that I never would have even thought of, never would have known, wouldn't have been able to consider because I wasn't a part of that community at the time. And so that's the thing about becoming a community member. You've got to be able to sit down and listen. And so the principle of working backwards, it just applies so well in that instance. And so that's the first thing. It's listening, understanding your customers, knowing who they are, and then trying to get as many perspectives as you can. And the next thing I would say is think big with your customers, right? And think big on behalf of your customers, but then from there, start somewhere, because if you try to execute on the really big thing all at once, now it may not go as well as you had hoped it would and you could actually diminish trust. So we started working on just a couple of things based on customers' needs. And as we were able to prove that they were successful and constantly get that feedback from customers saying, yeah, this works or that doesn't work, that's how we then eventually started to scale the program. Yeah, that trust angle is a big one because you look at trust. If you overplay your idea and it blows up, then no one's going to be motivated.  I love that insight, great call out there. What about this think big space you mentioned and that other example about in the school because I like this idea of having this think big space that you pointed out. Is that just a place that you guys could provide or was that something that they did the customer did or the community did? Can you share more about the think big space? Yes, our think big spaces. So the think big space also started as a result of sitting down in a conference room with some teachers and administrators in a local school district actually here in the Northern Virginia area. And the teachers were talking about the fact that as teachers, there's a lot of emerging technology and it can be difficult to keep up with what's next. What's current, what's next? How do we help our students prepare for jobs that may not even exist right now? And so it just seemed to align so well with our leadership principles within Amazon, learn and be curious, think big. And initially, they, throughout the idea of a tech lab and we started working back and forth and thinking, well, how do we make this a space where students would actually come and learn and explore and make things and get their hands dirty and really be creative and tie it back to technology and just being really disruptive. And together we came up with the idea of, hey, we got to teach students to think big. So we started working on the first think big space together, the school district actually hired an instructional lead and we worked with them to design curriculum and now there's a classroom, it's got eight Amazon's leadership principles on the walls and the students come in, they're engineers for the day. And we've been able to scale that program globally to other locations. We've got think big spaces in Ireland and Australia and India and of course in the US. And it's been really exciting to see how students get so excited when they're able to tinker and try new things and they know that if they break something, it's okay because we can come up with a way to fix it. And in the process of fixing it, they come up with something else and we teach them about working backwards and it's just really fun. It's an exciting program to be a part of and I've been excited just to see the growth and the way that our community members have benefited from it. It's really such a great program to think about it because you're training builders and you're giving them a place to be disruptive which is a natural part for young people to do and do it in a safe environment where they can build something and have fun doing it. It's amazing. So congratulations, that's a great program. Let me get into the theme here on this International Women's Day around breaking the bias is one of the core principles of this year's event. Globally for International Women's Day, break the bias as the theme. Where do you see bias and what would you like to see change and what does change look like? Yeah, so I would say with the experience of setting up in communities, activities and also collaborating with schools, what we see is that bias starts early. This is not something that people show up for work and all of a sudden there's all of this bias. There's bias in the way that young people and students are socialized. And so you start to see things at an early age where girls may be encouraged to do things that are different. So maybe girls are not encouraged to take on leadership roles or they're getting pushed into the arts. Of course, there's nothing wrong with arts but we should be encouraging people to pursue certain areas based on interest and not on gender. And if we want to really break bias, we've got to think about the seeds that we plant. So we've got to be really careful about what we say, how we nurture. You know, it's about you can do this.  No, you're a girl and you belong here. You should be here. We need more people like you.  Like you've got to start telling students this at an early age because all it takes sometimes is one person to tell a student that they can't do something. And if they believe them, then it can change their whole trajectory. And so for me, when it comes to breaking the bias, it starts really early. It starts really, really early. Yeah, and I think, even like the thing, big program you mentioned, which sounds so exciting. It's just providing access. And I think having an open collaboration is key but role models matter too. You want to see people in there too. I think this comes up a lot. What's your view on that? Because when you see people in positions, they're inspiring. And I think that's also comes up a lot in these conversations. Yeah, definitely. When you see people in positions and you see people who look like you, you see yourself in that person and you say, hey, maybe if they can do it, I can do it too. And so it is important for us to have great, strong role models who can show up and who can be there for students. That's one of the things that we try to do with our programming. So as we develop programs like the Think Big Space, it's not just, okay, well, we have a Think Big Space and that's the end. It's we have a Think Big Space and our employees are coming into the Think Big Space. They're engaging with the students. They're volunteering. They're taking on causes in their community. And it provides that natural mentorship and ability for students to just see themselves. Because again, if you don't see yourself reflected, then you also may be receiving a message that says, okay, well, that's not for me. Yeah, I was talking with a leader at AWS and she's in space area. And we were talking about how the younger generation are nerd natives, she called it. And they're born with inherent tech now. So unlike when we were born, we had to kind of just found us or we stumbled into it or we got addicted somehow to tech. Now they got the tech around them. And I think this is an interesting new dynamic that could play well for the bias issue. And we'll have to get your reaction to that. As the generations come in, they're seeing all the world problems, they're seeing the digital transformation. It's native to them. So I wonder what your thoughts are, how we could be better at, I don't know, shaping the paths. Multiple pathways seems to be many opportunities. So if people are nerd native, how do we do that? So we've had a great riff on that. I'd love to get your reaction on that. Yeah, I think that we have to make sure that we are fostering this idea of playing outside of the box instead of in the box. It used to be with really traditional careers.   If I want to work in tech, what do I do? Well, here's the thing with tech, you're engaging in tech so much. I remember that when my nephew and nieces were little before they could even read, they could do things on my phone. Like I would get my phone and all of a sudden I had all of these game apps. How did they know how to do that? It's like you can't even read a word, but you can put all of these apps on my phone. They're engaging with technology and so how do we take that and nurture it and say, hey, just embrace it. Just put more technology in front of students. Let them break things, let them fix things. I remember being a part of a panel with a woman who is an engineer and she said she became an engineer because she liked to break things. So she'd break her computer and she wouldn't get in trouble for it. She would be told, hey, figure out how to put it back together. And so if we can create more environments and encourage students, it's not about perfection. Let's be inventive here, let's try new things. Let's think outside the box. Think big, don't find a solution. Go find an issue and work backwards from the issue that someone is having to come up with a solution that works and then get feedback. That process, that can start early. It doesn't have to be once you're in a full-fledged career. You can start that at any age. Kind of like a great insight. Final question, what's new for you? What are you going to be up to? What's next? What are you going to break next? What are you going to do? So what's new for me, I now lead inclusion outreach within AWS for our data center community. And so I'm back really to square one when it comes to doing a lot of listening, trying to understand, understanding what the things are that are pain points within and outside of the organization. And I'll be working with employees and community members to continue iterating to continue solving problems and working together on those solutions. And so I'm really excited about it. Hopefully at some point we'll be able to come back together and I'll be able to give you some insight into how that's going. Well, we certainly will. We appreciate your time and thanks for joining our CUBE community. Really appreciate it. You're now CUBE alumni. We're always, door's always open here at theCUBE. And we want to hear more of those stories. We're going to do a lot more coverage and a lot more sharing of stories, certainly in this area. That's important and we're committed to it. And thank you for your time today and sharing the insights and your experience on the Women in Tech celebration of International Women's Day. Thank you so much. Thank you, happy International Women's Day. Okay, this is theCUBE. I'm John Furrier, your host. Thanks for watching the presentation of Women in Tech Global Event, celebrating International Women's Day. This is the season one, episode one of our ongoing program that we're going to have here on theCUBE. Thanks for watching.