 I work for Dell. I'm also an open-stack foundation board member, which is where I was yesterday. And I will, this is meant to be interactive in a discussion. So we're gonna tee things up for that. So please, we have a lot of microphones. I want this to be something where we can all collaborate and discuss things. Because I will tell you that while I am an enthusiast for both Quantum and Fog, I am not a deep expert in either. And that's actually the rationale for this discussion. So let me get, I'll go. Can you see the ether pads if I do it? Oh, that's cool. If you're not used to ether pads, it'll be obvious as we go. But I did tweet an ether pad for this session so that we can take notes and do some collaboration because my goal here is really to ask questions and then entertain some discussion. Maybe have some fun, we'll see. Yay, okay. Quantum Fog is a physics term and it's a conglomeration of Quantum, open-stack Quantum, which is our network abstraction and APIs and Fog, which is a abstraction layer for programming against multiple clouds. We will talk about what those things. This is the physics definition of Quantum Fog. And more simply, Fog IO, which is the project, is an abstraction layer. And we'll talk about some of the use cases. How many people are familiar with Fog? So I have to know whether I define this or not. Aha. Okay, Fog is a class of API abstraction tools. JCloud's being another one. There's some in almost every single language. Fog is one for Ruby, which is actually what the next slide is showing. For Ruby to allow applications that wanna program against the open-stack APIs to be able to abstract the APIs, not have to deal with REST calls, but deal with semantic objects like servers and networks and things like that. So there are a lot of tools in the marketplace if they're based on Ruby or Rails that use Fog as the abstraction layer. And then the interesting thing about Fog as an abstraction layer is it's not limited to open-stack. Fog is a generic and existed before open-stack. It's a generic API shim that allows you to talk to Amazon or VMware or Joant or whatever clouds you happen to a rack space before they were open-stack enabled. And that's really the benefit with this. So if you program your program, if you're writing in Ruby, then your application can be hybrid cloud or multi-cloud, depending on how you define those terms, and take advantage of that. Right, Fog handles the abstractions. So the fact that rack space and HP's public clouds are different is handled as an abstraction, right? The fact that an open-stack deployment might have differences in how it's deployed. You would do that. The reason I wanted to do this talk goes back to an email thread that Dan Went and I were having on the open-stack mailing list about the dilemma, and this is operative to this discussion, about the dilemma between Nova Networking and Quantum, right? My team had actually done some work to see if we could bring some of the working Quantum back into Nova Networking. That was not greeted with much enthusiasm on the list. And it really came back to a migration challenge, right? We've, people understand how to use Nova. They understand how to use Nova Networking. Quantum is something new, right? And so the question really comes back to not how do we make Nova Networking more robust, but how do we encourage people to migrate and to start using Nova Networking, or sorry, using Quantum instead of Nova Networking. And that's really the operative question, right? That is really the thing that I'm hoping we'll discuss and the thing that we need everybody's perspective on is what things can we do as a community to help people embrace this new Networking API and make things easier. And so the thing I chose was Fog because it's used in the tool chains that I use, right? It's used in Chef, it's used in Puppet, it's used by our partners like Morph Labs who've used it as an API layer to address OpenStack. It's used in our own product. We just created a Fog bar clamp so that you could look at the API of the OpenStack deployment that you just did. All those things are really powerful ways to start leveraging OpenStack. And so we'll walk through this. I absolutely want you to interrupt me and ask questions. And if I say something that seems wrong or you want a challenge, please do that's what the point is here, right? I want people's feedback and how they use it. How many people use Fog today? Not that many, okay. So this is gonna end up being a Fog sales pitch. It's good, okay. That's fine. And so this is what I've been talking about. So when we look at what we're doing with Quantum and what we look at what we're trying to do, a lot of the audience I was thinking we would have would be about somebody who's already using Fog, right? Who's using Nova. And this is really what the story is. And even if you say, hey, this is great. I want to use Fog. Do people understand what I'm saying about the use case for Fog at this point? Should I spend some more time talking about it? I have a slide for that. Let me slip forward. Yay, okay. So what do we want Fog to do? This is specific sort of the Quantum Fog pieces, but let me talk about this in the case of Fog. So here's our use case. You want to use OpenStack. Otherwise you wouldn't be sitting in the room. And more importantly, you want to build automation in front of OpenStack, right? So that automation might be something like DevOps tooling to help you do a deployment and help manage a broad infrastructure where you're deploying a lot of servers. That's great. You might choose to also write an API shim layer in front of OpenStack so that you have a dashboard for your company, right? I've seen a lot of our customers choose to write a replacement for Horizon. They want to simplify things. They want to integrate it into their tooling where you might already have enterprise tooling where it would be really helpful to show what was going on in your Nova Compute infrastructure. So for example, you might have already gotten something where you want to list the number of VMs or do a chargeback system or you want to help, you have an automated system where somebody can request a virtual machine. We see a lot of customers like this. They already have a way like a helpdesk system like Remedy or something like that where a customer can say, I need a virtual machine and it goes off and does the work or creates a trouble ticket or something like that. If you already have that, giving somebody dashboard is great, but it doesn't really help you with the trouble, the ticketing system. So that's where people would use Fog. They would take Fog, they would put it in front of their ticketing system and then it would allow them to then create a virtual machine in return. Hey, here's the information for your virtual machine and now you can go use it. So does that help clarify the use case? If you're doing DevOps deployments with Puppet or Chef, both of which use Fog, then being able to use quant, being able to use Fog is embedded in those tool chains. Okay, so you might be using Fog and not even be aware that that's the underlying mechanism for this. And so if you're in that case, then what I'm gonna talk about is really significant because what's happening behind the scenes is your tool chains do not take advantage of quantum and are not helping migrate you into the next range of infrastructure. So if you wanted to deploy quantum, you'd want to make sure that the tool chains you're using are actually taking advantage of that. People have any other use cases for Fog, the size ones on... Anybody here trying to build an application in the ecosystem using Ruby or Rails? Is that a... Excellent, okay. So that's the point with this and what we want to be able to do is collaborate together and figure out what that needs to do. Right, you're gonna have to match Verizon, you're gonna have to do transparent things. Verizon, of course, is Django and Python. You know, there's no reason that if you're comfortable with Rails and Ruby, then you shouldn't be doing that. Different people have different needs for doing it. We could have the same talk for Java-based API layer. We could do other things. For us, we do a lot of Ruby, so this is a very natural fit. So let me go backwards. So the challenge here with looking at Fog and what we want to accomplish with Fog and QuantumFog is that we want to make sure that we're building, that we have the tooling that we do builds into our workflows, right? I don't want to tell you to go program against the REST APIs for OpenStack. While that works, you're duplicating a lot of effort. At the OpenStack meetup, we had somebody who chose to do that for fun, which is great, but it took him a couple of weeks to get it all working and debugged and tested. If you use Fog or one of the other shims, you don't have to do that. You can leverage the API changes, you don't have to reinvent your application if somebody changes the APIs. And so one of the tricks here is that we really want to think about what's going to help people move to Quantum, okay? And so if you're looking at Quantum, how many people are going to deploy OpenStack with Quantum now that it's core in the system? Wow, how many people are using Nova Network for deployments? See, a lot of people are doing both, which is actually one of our core use cases for this. So here's the deal. Especially if you're doing both or even if you're just doing one, the idea, and this is one of my concerns with Quantum, while I'm very enthusiastic about it, I'm also concerned that it's adding another barrier, or back to barrier to adoption for customers who want to use Quantum but don't really know how to do all the Quantum work. So if you're going to set up a new virtual machine and you want to attach it, and my goal here was not to train you on Quantum, but if I want to build a network and attach a port to it and then attach the VM to the port so that I have network communication, I need to do all those things to get my virtual machine working in Quantum, then I need a way to make that all sort of transparent. If you're dealing with customers or users who are trying to adopt the cloud, if you present a barrier where not only that you have to get a virtual machine, you also now have to know which networks you're going to connect it up to. We're adding complexity, we're not necessarily helping our users adopt OpenStack. So that's a lot of what we're trying to do. And at the same time, we're trying to help people, if you're using the old Nova Networking, the current Nova Networking, and you want to bring in Quantum, you want to be able to help people with the transition. Questions, does that make sense? I need nods back from people so that I can, not sleeping nods, but nods. Okay, and then there's another major question in this which is really interesting and hopefully we'll get to, which is if we embed Quantum, how does that impact Amazon? How does it, right, Fog is designed to be able to be used against an Amazon cloud or a VMware cloud, that's one of the benefits. So one of the questions that I have for the audience, for everybody here, is can we, how do we cope with the compatibility issues? A lot of what Fog does is very straightforward. I need a VM, I need to boot it, I need to shut it down, basic operations. They don't really talk about how you build a network and how that translates into Amazon clouds or VMware's clouds. When I submitted this talk, there wasn't a Quantum, I wasn't aware of a Quantum Fog, there is now Fog, Quantum Fog, crud, create, read, update, delete capabilities. And Fernand, I don't think he's here, no. But this is, this came in a couple of weeks ago. So today with Fog, you can go in and you can actually do the basic operations, right? This is great, because I didn't want to have to work to get this done. But the code is pretty straightforward, it uses the Quantum API to create a network, create a port, attach a server to a network and a port, crud, the basic operations. It's not what I wanted to talk about. So having this done, it makes things easier. This is the question I was asking, I'm gonna skip forward to that. That's a Quantum Fogger, by the way, I didn't even know when it existed, it's amazing. So these are the operative questions to me that I came up with, and there's probably some more and I'm hoping you'll come back with these. This is cool, Quantum, in the background, this is Aerogel, which NASA invented to collect Stardust. Conversion between physics and cloud, it's awesome. So what we've got here is, the first question I have is if we're going to try and do automatic behaviors. So if we're doing fog, right, do people now understand pretty well what fog's gonna do, right, and now we've talked about there's a fog API already for creating a network. We don't want that to go away, we need it, but if the systems, if you have a Quantum-enabled system, having a VM without a network doesn't make much sense, should our default behavior be to connect a virtual machine to create a network attached to the network, set up the port and make things go by default? I'm looking at Matt, because I know I can see Matt's thinking about it. Well, that's right, I mean, this is, my purpose here is not to give the answer, I don't know, right, there's a part of me that thinks that if we make these default behaviors in this, in Quantum fog, then it makes it easier to adopt, right, obviously, you have to test if Quantum exists in the cloud you're attaching to, then you wanna do it. We could look at what fog's already doing with regards to storage, if anything, and what the overall breadth that we want fog to be. I haven't used fog all that much, just used it to spin up a couple Amazon machines and then repurposed it for the service provider that I was at, could spin up service provider machines, but we never even really went into storage because we had a default storage that we were giving everybody. But the folks who are looking at fog and storage now, saying, oh, I wanna be able to hook up LUNs and I wanna be able to hook up larger or different kinds of storage devices, and do storage failover, can I look at object, can I look at block storage? The same kind of questions come in on the network level and usually you'll have some sort of network management tool that's making these decisions or helping you make these decisions that you already have in place or wishing you were having place, same with storage. So my recommendation would just keep fog super simple. And that's, I think that that's a valid answer, right? If fog only does the CRUD operations, then it's, you've got the access to the underlying systems, right? And storage, we don't have the storage pieces right now, we have to get the sender APIs in place and have fog adapted to sender and do those things. Anybody have a response or a comment on that before I keep going on the, do we have another mic? I know there's two mics, thank you. Knowing how Nova Networks is planned to be completely gone at some point, I think the second bullet allows switching between Nova and Quantum, I would say no, because the people who probably care the most about this are probably using Quantum, and I don't, I mean, unless you have a business reason to go and backport Nova, networking support, I don't expect anyone to do it. But well, but my thought on this is that Nova networking sort of works today, right? If I deploy a virtual machine using fog, it's gonna attach to the networks that are default Quantum networks. So I already have that behavior. So the question is, do I then, how much default behavior should I mimic? So if I switch to Quantum, am I gonna get the same default behavior to attach to the same networks? That's my question, and I'm not. I just don't see a lot of value trying to, I mean, the thing about fog is the work that gets done is the work that people want. Like, there's nobody, none of us in here is paid to work on fog as our day job. Nobody is. I mean, Wesley, he works on it some, but he has a day job. And the people who contribute are solving scratching their own itches. So we can talk about what we'd like to see, but if you want it, you're gonna write it. That's right. And from the chef viewpoint, we haven't gone into networking much yet. I've, storage will probably come next because someone will want it, and chances are good it will come because somebody has to have it and they have a business reason. So we can talk, but it's fog. People are gonna do what they want. And that, which is the core use case, I completely agree with you. I think from my perspective, there's an element of, is there, the reason I wanted this talk is, is there a way that we can take the existing fog users and help them migrate to quantum? It's right, are there things that we do as a community that encourage quantum adoption and make the transition easier? Having that default behavior may make the old style of Nova Network seems to me would be very beneficial, especially if they just have no experience with dealing with piecing together networks and things like that. So to automatically, obviously as an option, having an option there to say just automatically, attached to a default network kind of thing and defining that default network, that kind of thing would enable adoption. It becomes less disruptive to adopt quantum at that point and you have to do less work. So it eases the transition. Is that something that you think your customers would care about? No, I mean would we care about it directly? Because the customers never see that in essence and hopefully never have to. It probably to us doesn't matter. I mean we're pretty deep into the networking layer stuff anyways so I don't think for us we would need it, but I could definitely see if you're trying to get into quantum that would certainly ease the path. Right, so I'm trying to figure out because there's places where my team as an adoption assistance for adopters, we're looking at places where we can contribute to fog in a useful way. Right and that definitely comes to his point is unless someone has some reason to develop that feature, it's not gonna be done. In general with people that have their own agenda probably never get done because those that actually are using it to that extent and contributing back already know how to piece these things together and just don't need that default behavior. But if there's a third party that wants quantum adopt more adopted more widely and is willing to put in some time to it, that would in my mind be an area that would benefit quantum adoption. And that's part of the key. So I mean one of the questions back along those lines is how many people here would are willing to invest in helping quantum adoption? Is that something that people care about in this audience? It might not be. How many people would if you were gonna deploy OpenStack would you use quantum instead of know the networking at this point? Not that many, okay. And this actually underscores where my, you were not, what was your, you were nodding? No, we were just saying it is a big change for people. It's a huge, here's my concern and this is sort of where Dan and I went back and forth. And I put in this talk specifically because I felt like there was no way to answer this. Which is, you know today our customers are probably gonna deploy Nova Network. And so we're gonna continue to have customers deploy Nova Network in the field. And that will probably not slow down. Percentage wise it probably will. But for this release, next release, right? Probably on, we're, and I know we wanna deprecate Nova Network and transition people over. The challenge is the more people deploy Nova Network today and just based on the response I'm getting from the crowd, either you don't know or you're not that committed to switching over to quantum, then that transition is gonna become something we actually have to deal with. The community who wants to deprecate this code needs to deal with, needs to provide off-ramps for Nova Networking. And so when I look at our customer base and our deploys and the things that are going, you know we need to help our customers off-ramp. And so that's why these questions to me are really important. Go ahead. Can we pass the microphone? You're really loud. You know, you might. Yeah, you need to be able to talk about it. Yeah, right here. For Fog, one avenue is to help quantum adoption which is one of the concerns you have. It wants to be a quantum client and what you want to do there is expose as many of the nooks and crannies and special things about quantum in a Ruby API and people have to deal with all the rest stuff. The other thing is that your first question goes more towards is what's kind of the network API model that Fog should expose? And I don't think you can just say that, say would it be useful to do X, Y, Z by default? You really, if you want to do that, you want to make it as much of a cross-cloud API as possible and you have to look at what the individual backends provide and how much abstraction you can give people here. Things that, and that's kind of, I mean that's one of the things that's kept us in the past from using Fog is that the cross-cloud abstraction is really not that strong, right? I mean it's more, it's more a collection of clients which is very useful in its own right. But the cross-cloud model is not as built out as it should be. So let me turn that around as an additional question. So if Fog adds quantum API support, it is moving away from cross-cloud capabilities, right? Those API calls for quantum are not gonna work against Amazon, they're not gonna work against VMware. So the value of Fog as a cross-cloud scripting platform are decreased. So how do you see us being able to keep, what level of behavior should Fog exhibit on the least common denominator, which to me means automatic behavior, but what type of behavior do you see keeping that valuable? I mean you have to look at the different backends you want to provide. I mean the cross-cloud API, if you want it to be useful, has to really follow the kind of things that whatever you see as your main targets gives you. And that means that some of the quantum things will probably not be exposed in that API. Yeah, I was gonna say, does that assume that there is your- Yeah, some of it will be automatic magic, right? If you decide that for the cross-cloud API the best thing is to, because that's what the other things give you and that's kind of the API model you want to pretend is there to use as, is that that's automatically network created, then yes, that's what you want to put in. And that might require a lot of gymnastics inside the library to actually make happen in each of the backends. Yeah, I think that's what- Or it could even be two public cloud providers, right? So if somebody is scripting against their managed private cloud, right? Then you go to script against a open stack hosted cloud that doesn't support quantum, or maybe does actually, more likely does support quantum, and your private cloud doesn't, or it's a VMware cloud, then yeah, this behavior, right? That's key here. That's why the crud to me is not that interesting. It's important, we have to have it, but it only helps somebody who's dedicated to using quantum, and it moves them further away from your point, which is that I'm now cross compatible. So, boiling that back down, I think that we are looking at the need for some automatic behavior to make sure that if you do something non-quantum in fog, that it works if it's quantum or Nova Network, and then ideally it probably works if it's VMware or Amazon. So, go ahead again. I think the point I was trying to get at was, you need to define the API, right? That's what drives these decisions. You need to define what the model is you're going to expose to users of fog. Yeah, the challenge is fog is its own API already. So, we don't want to necessarily add in. On the network front. On the network side, right. And I'm a big fan of, you want abstractions. The phrase I always use, abstractions are really useful until they're not. Which means basically that, and this is why I like a like Chef, and what Chef does. It's like, hey, there's these great patterns and you can use them, but if you just have to take a hammer to something and install it, just, sure, that's fine, it's built into the system. And same thing with Ruby. Ruby's a really good example of that. Use these conventions. They work until they don't and then that's okay. Nobody gets upset, right? But that's, the challenge is, and this is what's weird about fog, like any of these things, is they are themselves their own APIs. And the fact that a server object is a server object in fog, is it's a programming interface to server. And you can only extend it so far without breaking the cross cloud capabilities. And at that point, we really have an open, and the question, actually, sorry? Well, I mean, the point of fog, right? Mm-hmm. So why? Just build. Yeah. No, it's not that it's already done. It's just not there yet. And that's one of the things that I asked myself about when I first started trying to use fog was why don't we just have a Ruby OpenStack library? Right, because maybe that's the right answer. And so, and this is the subtlety between fog, this being a fog discussion and just being a Ruby OpenStack API discussion, which is the purpose here is cross cloud scripting. It is to be able to use, I mean, you guys used fog for a reason as opposed to just writing the direct APIs. Why, was that a objective for you? Or is it? I'm gonna ask you to identify yourself. So the audience knows, and so you guys can actually get credit for the work you've been doing. This is Hunter. He's a director of development for Morph Labs and his team has been contributing back a lot of the fog stuff. So it's good, it does its job. And like someone said, we add to it as needed and out of the Essex support, so. This is, we're looking at where I'm right, obviously from Dell, we're looking at where that we wanna make investments in fog so that we can work for hybridting, we can work for adoption for quantum. Those are important to us. Yeah, when I mentioned arbitrarily that third party that might put some time into making that abstraction layer a little more abstract, certainly I was referencing Dell and Dell probably has that motivation to dedicate the resources to do that work potentially because for them, it's adoption is the key. So. And one of the things that I actually is worth discussing is that this isn't especially worth it because of what the conference is and what it's about. And so one of the other things I do is I run the Austin OpenStack Meetup groups. And so it is, it happens that Rackspace and the Rackspace Cloud and HP and the HP Cloud and Dell all come together in those meetings. And one of the things that we all agree is that having fog and J Clouds and different APIs helps people with adoption. And we all have a motivation to help people adopt these types of technologies. So there's a lot of motivation for us to be a participant in that community. And for the other, right for the public clouds to all be participants in the community because that's that drives us forward. Oh, good. Okay, so we've covered use cases. Transparency versus opaqueness was one of the things. So I'm because I'm planning to start doing some of this work like Matt was saying. The way this stuff happens is when people do work and it shows up that people have a feeling for opacity versus transparency on this. Yeah, go ahead, Matt, it's floated back. So fog has a mailing list, very low traffic. It has an IRC channel, very low traffic. So I would say cross post to the fog list and the OpenStack list saying, you know, here's what we plan on doing and probably Morph Labs and Opscode and Puppet Labs will watch. I know, that's funny. Or where appropriate, we'll get involved. I mean, the maintainers for the OpenStack provider are like Hunter and Todd Wiley and Dan Prince. So you could probably find all those guys here. Yeah, and I was hoping we would drive the dialogue and have some of these discussions, right? Because like I said, I'm not the fog king. That's not a role I've taken on. I'm really trying to figure out where, you know, what we should be talking about with this and how we should be doing the designs. So yes, we'll definitely do that. Do you have a thought from your experience on this? We're fans of just-in-time development. That's reasonable, no, it's perfectly reasonable. Yeah, so I think we answered the last question, which is if we don't do generalize, we're not accomplishing the mission. So, which probably means more least common denominator, but at least you're providing some type of capabilities with that. And this is something where, you know, our goal is for people to be able to get the most value out of their OpenStack cloud as quickly as possible. So when I show up to a customer site and say, hey, you can use fog and start doing some scripting, it makes things easier, right? It allows us to do tests. It allows us to keep moving things forward. That's probably the place, actually speaking of first use case and just-in-time development, place where we'll see our adoption and adaptations for fog or probably in our test environments and continuous development. So we wanna be able to make those things work. That is also quantum fog, yeah. Okay. Sorry? No, well, this isn't physics. There's a quantum, this is hilarious. Have you seen this? The research, yeah, I don't Google this stuff at work, I take it. So yeah, there's a quantum spray that apparently they made alcohol small and then claimed that you could have a spray and it would be equivalent to three drinks. But, yeah, the disinfo.com is the site. To resolve it. This guy liked it, I don't know. Exactly, that's the exact connection. Yes, waste. So one of the things that we want and I think Matt's really underscoring this is this comes back to applications, right? Are there people in this room who are thinking through applications that they have for quantum fog that would actually be turning around and saying, all right, I think I get it, I can use fog if I need to do some type of, I have some use cases for fog. Are there people in this room who would, after this session, turn around and say, hey, I actually wanna collaborate on this, I wanna work on quantum and fog abstractions. You wanna talk through a use case? Let's see if the legacy opens in, probably the guy who lost his shell spirits over the years, kind of feeling around to see what, what. Cool, that's a really good use case for it. And would you consider quantum when you deploy up in stack, if you pick up in stack? Yeah, I also pulled up and they actually ended up with already from where I've been I've been popular with the quantum slide, I'm like, oh, here's the load balancers. If you're doing Greenfield, go quantum. The, yeah, yes, everybody's nodding. That message should be loud and clear. The challenge is quantum is gonna be more complex. So we're working to try and help people with the complexity for it. And I know a lot of other people are, but it's still there and this is part of that attempt for us. Just like if you, yes, definitely. So that's right, I mean, we're talking about things that really help people build abstractions that they can reuse across clouds and do that. And some of this, I think, and this is a whole nother question, couple slides back, which is, do we then try and push these changes into other cloud infrastructures, right? I know Amazon's not gonna give you a lot of choices on which IPs you get, but VMware could give you a ton of choices on how you set up your virtual networks and how you connect things together and stuff like that. So, at some point, we have to figure out that we're back to least common denominator as I go through that. Other people I've used cases they wanna talk about? Thank you for sharing yours. It's good, yeah. I have one that's not quite an application. I'm the maintainer of Apache Delta Cloud and what we're doing is we build restful APIs. We started with our own restful cross-cloud API. We've added a DMTFCME, which is an API standard and an easy to-front end. And as part of what we're doing, we have all these back ends that talk to different clouds. And I mean, over the years, I've talked to Wesley a few times. Good. The idea, yeah. So actually, I wanna pause you for a second and make sure that people understand, right? He's talking about the Java version. No, Ruby. Oh, is it Ruby? Yeah. Oh, okay. Now I'm doing a little bit. So it's Delta also? Delta Cloud is a Ruby. I thought it was, okay. You're right. I'm thinking J Cloud's Delta Cloud is Ruby. I'm sorry. No, so Delta Cloud, we're doing a restful API, right? Not an in-process API. And what we would have left or what we would love to have is that for all the backend stuff, we can just plug in Fog and don't have drivers for EC2 and OpenStack and whatnot. And we've looked and we've looked and it's never been Fog, the abstraction that Fog gives you and the cross-cloud capabilities were never at the point where we were like, oh, we can throw away our stuff and just have one Fog backend. It always looked like it would still have an EC2 backend and OpenStack backend, and then it was never clear that in the end, it would be a net win for us to switch to Fog. Although, I mean, it makes a ton of sense. And this is, I still go back and forth, right? It's very possible that to make quantum really effective, we cannot bend Fog enough to make, and that's a possible outcome for this discussion is that we can't bend Fog enough to make it really work well for the capabilities that quantum's enabled and that the semantic definitions don't exist. And so, this is part of the purpose of this talk was if a lot of people had stood up and said, hey, we're using quantum, we're using Fog already, and we really care about migrating and we wanna help migrate. That would be a different topic. That would be a different conversation. So I had no idea how you guys would respond. Actually, I've enjoyed the conversation. I think we're about at lunchtime. I have cookies up here, if you wanna. They're actually pretty tasty. They're Dell cookies. They are Dell cookies, right there. Do the coasters taste good? So everybody, thank you for coming. I hope the format worked for you. This was, I was trying to drive a discussion. And I hope to see y'all online and helping build some of this cool technology and making things happen. So thank y'all for coming. Enjoy lunch.