Quick show of hands, just so I know how to do the stops.  Okay, so that's probably like more than half. So I skip through this. So if I'm going to fast on anything, auto-stop, let me know. And I don't fast on stuff. Okay, so basically, for those who don't know, so first question, what actually is a prediction market? A prediction market is a market on any event in the future that is to the result of which is unclear as of yet. So basically, this is an example. So here the question is, will the air train in Manhattan be repaired by July of 2020? And then there are two answers that you need to specify when you set up the market. You also need to specify how you're going to resolve this. So in this case you're resolving this by saying you are counting on an official press release from the NPA on the office of the mayor of New York. So you have these two outcome tokens and they trade individually. So at any one time they add up to one because basically at the time of resolution the one that comes through will pay out one and the other one will not pay out anything. So basically at any point in time some of these two tokens will be one and at the resolution time the value, the market value of these tokens will go towards what the resolution result actually is. So what is a conditional market? So a conditional market is a prediction market that allows trading on assets that are contingent on the results of other predictions. Let me go into that. So we find that in the real world that there are many, many examples of things that are actually interrelated.  So these markets, they all work together because Makedao has said that single-collateral die will run in parallel with multi-collateral die for at least six months. And clearly the answers, these are all yes, no questions and clearly the answers of these are correlated with each other. If you have an opinion on this, this will probably influence your opinion on the other one and the next one. So we've just put out a new framework for this. So let me explain you how it used to work in the old framework. In the old framework, you have a collateral token, say, for instance, Ether or Die contract. So the event contract here being, for instance, with multi-collateral die will remain at by November 18 and then that would have two outcomes, yes and no, this example has three outcomes, and you can buy the complete set. And then each of these outcomes you can trade individually. So each of these outcomes actually had a price at any one time. You can always take a full outcome set and convert it back into collateral token or you can wait until the event is resolved and then one of these outcomes will pay out one and the other ones will pay out zero. And there's a different flavor where basically the one-in-one plus gala, where basically you can go long or short and it's not binary, whether they pay out one or zero but they can pay out somewhere between one and zero but basically the idea is exactly the same.  What you, in the old framework, what you would have had to do was you would have taken a first event, made a market out of it, so basically you can have answers A, B, and Z and then you can put these outcome tokens as a collateral token into a new event contract so basically you instead of putting either in here you put the conditional outcome, you put the outcome token of the first prediction in as collateral token and then you get these derivative tokens so basically here the first event has outcome A, B, and C and the second event has outcome B and you end up with six event outcomes so A and high, A and low and so on. You may notice that you could also do this the exact other way around so you could also switch these around and you could also say basically now I use event two as the first layer and I get two outcome tokens on the first layer and then I put this into the second event contract and I get three outcomes on this layer so I end up with six tokens there and if you actually compare these you'll find that these are exactly equivalent basically the payout function of A and high is exactly the same payout function as high in A and in this framework these tokens are not fungible so you can't, the system doesn't know that these are actually the same tokens and this is just for two separate events obviously this gets way worse if you add more events so what we actually did is we did this new first fight it's called the condition token framework and what actually happens in this is you can specify any number of conditions so in this case we would specify two conditions the first one has three outcomes that's A, B, and Z and the second one has two outcomes that's high and low and you pick left token that you put in and then you get these basically you only get one set of outcome tokens so the condition framework that I call token framework mechanics so A and high and high and A are not the same token you can do a partial redemption so basically if you have a token A and high and high occurs so basically high occurs then basically all the ones that are low they become white because low didn't happen and all the ones that were high will become just A and high becomes A B and high becomes speed C and high becomes C so you can actually resolve some conditions before other conditions without actually destroying the highest A what you can also do is you can buy baskets so you can say I would like to buy not A so basically I would like to buy B and C you can set positions so basically if you already have two specified conditions say you have A and Y and you can append another condition say with three outcomes that's one, two, and three and then you will get A by one A by two and A by three and you can merge positions basically if you actually hold all of these these three now so you have A by one, A by two and A by three you can actually just get your A by token back for it how does it work? so it's actually one it kind of goes a little bit against a traditional smart contract design school it's actually just one big smart contract that anyone can append conditions so the one big advantage of this is that there are tremendous gas improvements and you can actually see that tokens that should be fundable are fundable because they are identical so basically whenever you actually end an event so a registry entry to this smart contract you can specify a maximum of 256 outcomes slots per condition and this is permissionless, no fees and anything can be specified as a market by the person who actually pens to that contract so this is something that's out there it's been audited you can add your own conditions to that if you choose to do so so let's go back to this example so now you have these three markets and as we said earlier these are all yes no markets so how many atomic outcomes would that be? just two to the three right so basically two times two times two so that would be yes yes yes yes yes no yes no yes yes no no and so on so that's eight and these eight atomic probabilities of what is going to happen in the future and it's actually going to give you so basically these probabilities the eight probabilities of what would happen in the future these are actually going to be consistent so basically if one of these changes so if say obviously these are correlated so if multi-collateral die does not go live then the multi-collateral die will not overtake single-collateral die either so basically if the probability for this change then automatically the probability for this changes depending on how the market actually traded these previously and I'll give you showing you this so this is, can you guys see this in the map? yes so so basically this is a different example, I'm sorry I should have used the same so basically here are the questions I will quickly leave the EU on the 35th of October with no yield with a boat of no confidence of Her Majesty's government who passed before the 31st of October and with it the AHA would have between Newton Island and the Republic of Ireland on the 1st of November so obviously these are again iterated so what you can do now as you can say I want to have this as yes and this as no and then it will give you the payout structure so basically when this is going to pay out it is going to pay out if this is yes and this is no and you're going to lose the investment if either the first one is no or the second one is yes what you can also specify this one so with it the AHA would say no okay so what you can also do now is you can make these conditions so say now this basically says if Britain leaves the European Union on the 31st of October with no yield so basically that makes sense but will there be a hard border between Newton Island and the Republic of Ireland on the 1st of November and you can now specify this and it will again give you the payout structure so basically if this happens then you obtain a position on this market but if this doesn't happen so if the Britain doesn't leave the European Union on the 31st of October with no yield then you just get a refund on your prediction so basically you can place a prediction on something that doesn't necessarily happen so basically it's just it's a contingent thing so basically this is obviously making a good interface but this is super hard just because it's not and even for a simple prediction market making a good interface is hard so this is currently still very much a feature product let me go back to the top so how does this tie into a futaki so basically can we do a quick show of hands again who knows what futaki is oh wow about half again so basically futaki is basically rich markets for governments so basically what you do is you create a market on a question that you would like to find an answer on and you specify a metric for which you would like to optimize your decision then you let people trade on this market and in the end you actually use this data to make a decision on what you would actually like to do so this is something that's going to be big in dollars and other decentralized decision making and let me give you a concrete example okay so say I have a company and I have the CEO and basically the company we're wondering whether we should fire the CEO so basically then we find a metric that we would like to optimize for so in case what would the quantity revenue be if we fire the CEO or if we don't fire the CEO that's what we're going to optimize for we could also optimize for something else so say we could optimize for employee happiness for instance but I'm not very sure yet so we let in the fact what we do is we create markets so what is the utility revenue going to be given that we fire the CEO and what's the utility revenue going to be given that we don't fire the CEO and then we see which one of these works out better and we use this to actually make the decision of whether we should fire the CEO so over here it turns out that some beliefs that if we fire the CEO the quantity revenue will go up so we fire the CEO people who said who traded on this other market so what's going to happen to the quantity revenue if we don't fire the CEO they'll just be refunded and everyone who traded on this market given that we fire the CEO they will make profit or losses based on the quality of their revenue prediction so why are conditional tokens important for this so basically for this kind of decision making consistent view of the futures actually super important so basically if you have different contingent events in the future or different events that are correlated having one consistent view of the future on which to actually base these decisions on where basically all information actually feeds into giving you an accurate depiction of the future and probability space is super important so basically one aspect of a useful map of the future probability space regularity and consistency so basically if one thing is going to change you actually want everything else and you want to change according to how these things are related then you quickly check how much time I have the conditional token rate anyone can append to this anyone who used this but we've actually built our own application on top of this so basically the prediction market is flawed in regulatory sense so what we've actually done is we have gotten a license from a financial market regulator to make sure that we don't actually get shut down so giving you good things first so basically the prediction markets we can offer them on anything but support to retail customers which is super nice they are not custodial and fully collateralized we have a market mechanism that guarantees your liquidity and it's denominated because obviously having this in a stable asset makes things easier because otherwise you're just conflating two predictions about the future okay so we have to do AML and KYC because we have this license there's 1% trading fee but this is not really bad we can trust the market and we are the oracle because basically we are the ones so we have the oracle we are the oracle on this on this instance why why do we take keep obviously because we well started with negative cash flow and we are regulating geriatrists so basically that means that we can offer this to anyone in Europe and most of the world except for the US and Canada I'm super sorry we are working on that once we have seen that this works in other parts of world so the beager and you can take part of it if you go to site.pm and sign up so basically there's a couple of markets live now and we started one of them at 50-50 chances so basically there's actually quite a lot of money on the table right now if you want to take the and you cannot Chinese citizen I'm super sorry about this we are still working on that but if you are not from one of these 3 countries ask would you please to take part currently you have markets such as on the price of either the transaction fees on a certain day and make stability fees so basically things within the ecosystem we will go to other markets so starting with political markets after this we have so noses we have an ecosystem fund and this run around just close but there's going to be another one this year so check that out on github noses and we are also looking for a couple of people to join our team so you can actually check that out on greenhouse I was looking at those conditionals and I'm thinking that each additional conditional provides an opportunity for you to have stuck the token because of do you see what I'm saying is that why you have noses for viewing to make sure that there's no obvious so you mean if there's no way to resolve it yeah like an unresolved question yeah so basically what you can do is you can buy up the and then just merge them together again so basically if you have an A-B question you can't resolve it you can just have both and just strike that off of your of your outcome token because you can also you can split and merge them even before the things happen if you actually have all the different conditions but basically specifying good argument and wording it in a way that is sensible makes complete sense and as a person who actually registers a new a new token basically a new outcome token you can say which which conditions you actually subscribe to so basically that's in your discretion as the person who creates this anatomy an outcome token so basically there's a lot of there's a lot of room for this to not work out if the markets aren't valid perfectly I have an additional one okay so you have those outcomes do you have like an expansion of that because a single sentence describing I mean it must be like a very deep description underneath that right everyone can understand mother but then it's like the deep description exactly the small print yes so your community right basically it's in effect and it's like a little contract that actually tells you how things are resolved and where we actually check for these things and basically on the so it's kind of a it's your question on the conditional token framework anyone can specify their own argument so basically that's on them on the conditions that we register yes there's kind of like a it's literally like contract that actually says under which conditions this will resolve and you also have to make sure that it will resolve in any case right from us so it's yeah absolutely very good question


Good sign. Hello, everyone. I'm Gal Sagi. I've been working on the networking side in OpenStack for the last two years now, with me presenting Russell Bryant. Hi, everybody. I'm Russell Bryant. I've been contributing to OpenStack in one form or another for a little over five years now and with more of a networking focus here in the last two years. So I'm really happy. It's a topic that I've been wanting to share for quite some time right now, and I'm pretty happy that it got selected, and we're going to show it to you. So I want to first share how it all began to me when I started to work on Neutron. It happened around two years ago, where I joined a large company.  The network didn't scale. They were hitting some problems with security groups and all sorts of problems. And they came to me and said, OK, please take a look at Neutron. Take a look at the insides of OpenStack, and either fix this problem, find us a new solution, or just write something on your own. And I started to look around in Neutron, in OpenStack, and it's challenging. It's a hard thing to even find an updated document to understand not what it's supposed to be doing, but how it's actually doing it. And the first thing that I noticed, and this is a misconception that I still hear even from experienced people, Neutron is not the reference implementation. Neutron is not the layer two, layer three agents, and the OVS implementation. This is just one implementation of Neutron. Neutron, in its essence, is an API and debiler. And there are around 65, I think, even more drivers in implementations of Neutron in the world. And each of these implementations is doing things a little bit differently. So I started looking and trying to examine and trying to see how things are working, what solution is best for our use cases. And again, it's hard to understand how each solution is addressing all the challenges and problems that I mentioned. And this is why we are doing this talk. It's important to understand that we are not going to do a comparison between the solutions. You're not going to finish this talk and understand there is one great Neutron solution. There is one fit for all your needs. It's something that's a little bit more hard than that. It really depends on your use cases, on your traffic patterns, on what you're expecting from your environment. Each of these solutions has its pros and cons. What our goal is to highlight you all the important things that you should examine and look in your solution. If you're looking for a solution or if you're building one, so important things to notice. We're obviously going to focus on open source solutions simply because they are open. And we can see how they do everything. But everything that we are going to say is also relevant for the proprietary solutions. So one place you can start, if you want to start just getting an idea of what's out there is our user survey. This is some data from the latest OpenStack user survey published within the last week or two. And one of the questions is, what Neutron drivers are you using? Now, the survey isn't perfect. Just point out a couple of weird things about this. There's one that I'm not sure it's a problem with the data or the website. But the first two things here on the left are something called 764 and 956. And I'm not sure what networking solutions those are. Maybe it's like a startup that's still in stealth or something that has some early customers, I'm not sure. But I think it's just a bug in the analytics tool that they're using to show this. So I'm not sure what those are. That's one thing. And there's another odd one on here that's Modular Layer 2 plug-in, which isn't quite comparable to the rest. The rest are networking vendors or open networking technologies. And this one's a little bit different. That's a part of Neutron. That's the most common driver interface used for all the rest of these things to plug into. So that, as an option with the rest, is a little bit confusing. It shows it as 32%. I suspect it's drastically higher than that. And it was just people were confused. We can get a lot of insight out of this information with all that said. One is you immediately get an idea that there's just a huge number of different solutions out there. It points to the fact there's quite a wide variety of use cases that people have varying needs and these different things suit different environments better. And there's also an obvious most popular choice and that we should pay close attention to. That would be the ML2 OBS driver also referred to as the reference implementation. That is the most commonly thing used. It's not a surprise. It's been part of Neutron from the beginning. It's the default and nearly all the open stack deployment tools and whereof. And it does suit most people to a degree. There's also quite a few that are using other things. But one of the things I would draw from this is no matter where you're going, how special your use cases are, you should really understand how the default one works. You should understand what it's capable of, what its shortcomings are, and understand the components because it's going to be referred to in documentation, examples, and used as a comparison point in a lot of cases. So I would make sure you at least understand that. And Gal talked about some of his journey as he got into open stack networking. And for me, this is where I started. I've been involved in writing an alternative. But the first thing I did is I studied this closely and tried to understand very well how it worked to get some inspiration for what I would do differently. So it's easy to jump right into technology. But I think there's a lot of other things you should be aware of when you're going to select some of these things. Some of it's maturity. If you look across this huge number of things out there, there are quite a range of states of maturity. And there's a lot of questions you might want to ask. This is particularly true of the open source ones that are talked about a lot and out there from the very beginning, where there's perhaps even more presentations than code. You need to dig into it and figure out what stage of development's and how long has it been around? Are people actually using it in production? Or is it experimental? I mean, is it even ready to be used in a lab? Sometimes things are talked about that aren't even ready for lab testing, really. Another, maybe this stuff is hard to figure out directly, but you can start looking for good signs of maturity. For example, an upgrade story. A good solid solution should be able to tell you that, one, it's upgradable. And two, very clear instructions for how to do so. And ideally, even a good idea of how that's going to work and not give you any downtime. Certainly no downtime on the data plane, but we even want no downtime on the control plane. We don't want your end users, the users of the Neutron API, to experience downtime. So what's their status there? Do they support that already? Do they have a vision for how to get there? That's a really good indicator of maturity. CI test coverage is really important in the open stack community. There's some projects and solutions that have really great test coverage running in open stack CI, some that have absolutely miserable test coverage. And it's quite a range, and it's worth looking. And especially if you're considering one of the commercial vendors, you should hold them to a better standard than some have done. Is there good documentation? That's another good sign of maturity.  And then you go look, and it looks like a dead project where there's been two commits in the last year. It's kind of really odd. So you have to try to figure out what the heck does that mean? Or is it actually a vibrant community moving quickly with lots of changes? And then what does the community look like? So degrees of openness. So Gallup mentioned that we're talking, kind of, we want to focus more on open source solutions. But to be clear, there's lots of proprietary ones. And actually, there's a lot of good ones out there. People use them for good reasons, whether it's tooling they come with, performance, whatever it is. There are good reasons. Don't discount them. There's the ecosystem exists with merit. But when we go to the open side of that, it's not enough to just say it's open source. There's a lot more to openness than that. And so in OpenStack, when we talk about what open means, to OpenStack, we have this document that describes the four opens. There's different to what we think is a healthy open community. So open source is part of it. You can have code that's open, but that only means so much. You can just throw code over the wall and publish it on somewhere, but that doesn't mean that there's any way to actually get involved. The design, so how does the project move forward? Where do people actually talk about the future? And can you be involved in that discussion? That's not true everywhere. How about the development? Where the code is written? Is that a process that you can participate in? Can you submit patches? Can you review other people's code? Or is it done? Is it effectively being done behind closed doors and then published up somewhere? In the community, at the end of the day, who's in charge? What, how do decisions get made? Is it a level playing field across organizations? Or is it an open project but effectively controlled by a company? I tend to think of that as a sign of a less healthy open community. So think about how all those things add up in terms of making a long-term bet on a technology and a project and whether you're willing to take risks if you start to see any signs of any bad signs. So some more comments on community. I talked about how I think it's important for a healthy community to be a level playing field so people from any organization have an opportunity to get involved, have influence, and play a part in where the project goes. So this is, there's a website called Stacklytics, very commonly used in the open stack community to take a look at. Some statistics about contributors to open stack projects in terms of code reviews and also commits. And these are a couple of graphs of the organizations contributing to the core neutron repository. It's a huge development community, lots of people. And pretty quickly looking at these charts, you get an idea that it's actually a very nicely, evenly balanced community. There's no one organization that dominates. I think the piece of the chart that's 18% is other. So there's a huge number of companies and it's well balanced. But if you start digging into other things in there, you can see the other end of the spectrum where it's open in a sense. But why is 99% of the work by one company? Now it's not necessarily a bad thing, but it's worth asking some questions. Could be something that's brand new. When things get brand new, it's usually championed by perhaps a person or a small team or at least a team at one company. That's quite common. So maybe it's just new enough and it's still sort of growing and getting that momentum to start then attracting lots of other organizations to jump in. Now it also could be that it's been around a bit, but it's not actually gaining that traction and the interest isn't coming from other organizations. So maybe the technology is not as interesting as they had hoped. Now it also can be a sign of an unhealthy community. There are mature projects with very large number of contributors that look like this. And that usually means that it's not really a community that's conducive for other people joining in. And I would look at it. Is that it, that is a bad sign and you might want to ask questions. So, control plane. So Russell touched some important things to look up when you're examining a solution in terms of the community, in terms of the companies that are working on. But we also want, of course, to evaluate a solution according to the technology. And control plane in this context means how your solution takes the neutron constructs, whether you use them in the Ryzen UI or you're using the API or any orchestration system and how it propagates all of these topology and security policy to the endpoints. And control plane is, as we will see, I'll show a few examples, is a very critical point in any solution. And as we will see, there are many ways to implement this rather simple task. Now, it's important to also notice when you're examining a solution, that some of them also use other libraries. For examples, for message queuing, RabbitMQ, or so on. And the same thing you're doing to the solution itself, examining its capabilities, you should, of course, also examine the third parties and other frameworks that it uses, because, for example, if you use a messaging, a framework that is not reliable, your solution needs to support it. So there are many different ways and different solutions to the problem of propagating the control plane. The two high-level areas that we see in solution are the centralized, which affect all the logically centralized SDN controllers, like Open Daylight, or ONOS, that control a set of virtual switches with OpenFlow. And we have the distributed solution, which has local agents, like the reference implementation, or local controllers sitting at each hypervisors, like Oven, DragonFlow, and Midokura. And this solution differs, but even the distributed part have different subsets of solution. There are some that are syncing the control plane, propagating this information using a message queue, RPC message queue, like RabbitMQ or ZeroMQ. And there are a solution that are using database-driven approaches where you have a logically centralized database and all the agents or the local controllers are synchronizing this information. Now it's very important to also understand what kind of information is being propagated, okay? You could have solution that propagate every change or every model in Neutron. You could have solution that propagate compiled flows or OpenFlow flows. You could have solutions that propagate policy or other thing that they define. And this is, of course, important because it defines the amount of information that needs to be propagated, how reliable it needs to be propagated, and it affects a lot of characteristics of your solution. Now I'm going to speak about one single pain point in when it comes to control plane. A usual OpenStack Neutron deployment looks like this. You have a few Neutron API servers, usually working in a cluster active-active approach with an SQL Galera cluster for the Neutron DB. So you have one database that is holding all the Neutron construct that you define in the UI or in the API. And then you have your SDN solution and it doesn't matter if it's SDN controller or any other solution that uses an external database, I think most solution do it maybe beside the reference implementation. And then these two database needs to reflect each other. Of course your solution might add the new features but when you are looking at the basic Neutron connectivity and security policy, then you are supposed to be able to derive one database from the other. Now the single thing of keeping them synchronized and keeping them reliable because you could have many API servers that are getting requests and updates on the same entities, that's a hard job. That's a hard job to keep. And during the time that I worked on Dragonflow I met a lot of people and saw a lot of solutions to this problem and sometimes people are saying, okay, this is a rare case, it will never happen in production. Okay, this is a 1% chance that it will happen, let's not address it. I can share my experience in the networking world. In production everything that can go wrong will go wrong. Okay, you'll see these craziest things that you didn't even thought are possible and it's very important that your solution knows to address and recover from this problem. Now even for the distributed case, if you don't have an additional database then you still have the local agents or the local controllers that are spread across the IPervisors and it's important that they will be also synced with the latest information and we'll get this reliable because we have here, as I mentioned, few neutron API servers so things can get out of order so it's very important that we keep things reliable and I'll not go over all the possible solution, we have journaling, we have DB versioning, we have a synchronizing threads so each one has its pros and cons but please look at how your solution solved these problems and ask the right questions. Control plane implementation is actually affecting your solution scale. It's affecting how many IPervisors it can support in one cluster, one OpenStack cluster, how much time it takes for changes to propagate to the entire system, how many changes you can do per second. The rate of these changes and of course you want to look for solution that has benchmarking and done testing and can show you results of these numbers, you don't want to wait and test it in your production environment, you want to test it and understand the implications of using a certain solution. So I've touched control plane, which is, as I mentioned, very critical to notice. Data plane is, we have our control elements and we're propagating the information to the endpoints and then we have some entities that actually the traffic traverse in this entities that's called our data plane entities and the one thing that people usually look is performance, like how fast our solution can be, how many packets per second it can process and so on. And this is an important thing, but there are other important things to notice. For example, how much resource your solution takes from each hypervisor or each server in terms of CPU and memory. So if your solution takes from each server 10 cores to operate, then that's 10 cores that could be used for user workloads. So pay attention to this. We want to gain data plane solution that don't lose traffic if control entities are restarted. So pay attention how your data plane entities work with control plane entities. You want to achieve zero traffic loss as much as possible. We also have some solutions have integration with specific and proprietary hardware. If your solution works only with a specific hardware, that's normally a bad sign, but you should know about it. But some solution also works and have integration with some sort of smart nicks or any kind of hardware. So definitely look up and see how your solution can work better. And if the benchmarking numbers that they're talking about are benchmarking of the normal case or of case when using all of these sophisticated hardware. Now the last point, I left it as the last point, but to me it's a very critical point that is missing in most solution today and that's visibility. Remember that we said that everything that can go wrong will go wrong. And when it does, you will want visibility and monitoring and debugging capabilities to your solution. So you want to be able to tap traffic and understand what's flowing there. Be able to see and understand the problems. And this is one area to me we need to keep working on because it's still missing. So anyone doesn't know what is open V-switch? Okay, so that's a good sign. So open V-switch is pretty much the common standard data plane entity in most solutions. It's an open flow virtual switch. It can also work in normal mode, but most solution use the open flow version where packets traverse in it. And it also has a DPDK version. DPDK to who doesn't know is a set of libraries that lets you process packets in a pole mode way in user space and it lets you achieve much higher performance numbers than the normal kernel stack. But the important thing to notice in these two things that if you want obvious DPDK, then in terms of feature parity, there might be some differences than the normal OVS. So if your solution uses specific features and these features are needed, then make sure they are also in the OVS DPDK version if you plan to use it. Now there are other variations of using OVS for middle net is an interesting approach. They are, they kept the kernel model but change the user space implementation. I'm not going to get into right or wrong here but just, you know, be familiar with this, understand the limits and query about it if you're using these solutions. I didn't touch it before but there are a set of layer tree only solutions available today. Two examples are Project Calico and OpenContrail. Basically you have routing from the VM or containers that you use. If you pick a layer two or layer three solution truly depends a lot on your applications and on your physical network as well. And I'm not going to get into it but things to notice is that Neutron, originally Neutron model, the concept of network was a layer two broadcast domain. And there has been some work in the Neutron community for routed networks to support the notion of layer three networks but definitely you should look how the solutions that you picked, if you pick a layer three solutions how they map what you configure in Neutron to the actual deployment, okay? So make sure that the behavior is as you expect it to be and also another issue that I see sometimes in these solutions is tenant isolation and overlapping IPs. So some solution expose the VMs and tenant IPs outside which mean you cannot have overlapping IPs for example. So some solution solve this in some way or another some don't, definitely something to pay attention to. So who knows what this animal is? You get a prize in the end. It's okay, I don't either. But apparently that's the EBPF icon. EBPF, anyone heard about it? You can raise your hand, so I'll see around. Okay, so EBPF is a really cool technology. In a nutshell, it lets you run a JIT compiled code in a safe way inside the kernel and attach this code to certain events that can happen in the kernel. It's a technology, some solution, there is a big project, open source project called Iowizer that is giving you examples and showing you how to use this technology. To me, it's still a bit complicated. It's not something that's like going to work for you and you're going to understand out of the box but it's definitely something that you should be looking at for the future and this is something that's maturing and is showing a great possibilities. In this regard, by the way, there is some work in the community to change open V-switch data path kernel module to an EBPF implementation. This will definitely increase feature insertion to the project. So these are not competing things necessarily, they're also complementing each other. Yeah, the work happening in the open V-switch project we covered with a little bit more detail in a talk on OVN yesterday but one of the portions was talking about what's happening in OVS and the work around BPF and looking at porting the OVS data path to become BPF instead of its current custom kernel module. There's a lot more differences. We talked about these broad differences, the control plane, the data plane and then there's this huge host of features that either not every solution implements or if they do, they implement them in very different ways and they can have pretty drastic implications on the performance. So one of them is SNAT, D-NAT. Is it supported at all? Probably is, I'm not sure if anything doesn't support it. It's pretty commonly needed for Neutron but they're implemented in very different ways. One of the key differences is is it done in a distributed way? And not just that but which parts can be distributed or not? That's complicated and it varies quite a bit across solutions so you should understand, one, where do you need NAT and how you intend to use Neutron and then how does that apply to the solutions you're looking at because it could become quite a performance bottleneck. Another one is routing. So how is L3 routing done? Is it centralized? A lot of things centralized all of that in a single place. That's how the Neutron reference implementation originally worked. It eventually gained some distributed capabilities but not all solutions can do that or some solutions do it entirely distributed. But also how is the routing implemented? You can do that, some project's implement that is purely as OBS flows for performance reasons. A more traditional way to do it would be to, if you're using OBS would be to layer that with network name spaces and use Linux routing instead. So there's different ways that can be done. Gateways, presumably you're going to be integrating your Neutron networks with your physical networks out to the world and you should understand the gateway solution. So different ones have different ways of doing L2 or L3 gateways and with L2 gateways, maybe they're software based, you can run those on Linux hosts or there's hardware based L2 gateways, some solutions can integrate with top of rack switches as your gateways. That's interesting, but not all things support that. Also, particularly with L3 gateways, what's the HA story look like? If a host or a node or device that you're using as a gateway goes down, how is high availability achieved? That differs quite a bit across solutions. In related to gateways, some solutions take advantage of this to make it easier to connect networks across multiple open stack clouds and not everyone has really looked into that problem space. So if that's important to you, you should start asking questions. Neutron has a core set of APIs, lots of additional optional APIs, load balancers service, VPN as a service or two common ones that have been around for a long time. Not all solutions support these things. So do you care? And if so, how does that your solution do it? And service function chaining, this is a more recent one and there's an enormous amount of variation on here. I'd say most things aren't even touching it yet, but there are a few solutions doing very interesting work here. And they're doing it in very, very different ways. So I would say that there's not necessarily broad consensus on exactly how this should be done, but you should dive in there and see what it's an area of innovation that's being pushed through multiple communities. Containers is another space. OpenStack has been traditionally around VMs and now we can do bare metal as a service. Containers are obviously a critically important workload and a part of data centers going forward. So how does your solution map to that world? If you're gonna invest in a networking solution for OpenStack, presumably you're making a bet on it and you wanna be using it for a long time and use it for as much as you can for your workloads. So in the OpenStack case, we have a project called Courier. I think there was a talk dedicated to that earlier. And Courier is a project that provides glue between the container ecosystem and OpenStack. It allows the container platforms to talk to Neutron directly to program the network. There's some benefits to that actually performance. Also having some integrated, a good integrated networking story. So perhaps you're not just running VMs on OpenStack, but you're running containers within those VMs and you can now have Courier as a path to having Neutron provide the networking for both of those layers, the VMs and the containers within those VMs without having to build a second level of virtual networking at the container layer. But if that's a mode interesting to you, then you should figure out which ones support that because actually most do not support that mode. Now hopefully you know more catch up and implement the interfaces needed to provide that but it's still a newer thing. And then also if you're speaking of containers, if you're getting into this, are you using Kubernetes? Then maybe you also wanna see what they're doing in that community. Are they providing any sort of direct integration? Do you have needs where you might wanna have Kubernetes talking to your networking solution directly and do they have any story around that? There's quite a range of status in that space. So with that, we can take some questions. So we did a good job, no questions. All right, thank you very much. Thank you.


Exclusive, extensive, continuous coverage of Hadoop World 2012. I'm John Furrier with SiliconANGLE.com. This is theCUBE, where we extract the signal from the noise and share that with you. My co-host for this event is Jeff Kelly, lead analyst at wikibond.org. The best big data analyst on the planet. Put out the first market size report. Influencer, Jeff, welcome back. Thanks, I'm not going to turn down the flattery, I appreciate it. Of course, yeah, of course, yeah. It's my editorial. But more importantly, we have John Christ of the VP of Marketing for Hortonworks in Sega John, welcome to theCUBE again. Thanks very much. Thank you. This is your event, and you know, this is the first event that you guys really had your hands on last year. It was Yahoo, Hortonworks was spun out of Yahoo. That's right. Very specific orchestration on your part on Hortonworks with this event, not to be very grandstanding, Hortonworks specific. Yep. And be very trustworthy and being a good citizen. Talk about the event. You guys put a lot of money into it. You organized it for the community. You know, kudos for that. But explain to the folks the event, it's not just Hortonworks, Yahoo's still involved. Sure, absolutely. Thanks, John. And thanks, Jeff. Very good to be back on theCUBE here again with you guys. Always a well-run activity. So, absolutely. So we tried very hard to make sure that the Hadoop Summit was a community-driven event. So we did a couple different things to ensure that in terms of building the content, wanted to make sure we embraced the community to drive the content that the community wanted to see. So kind of selected by the community for the community, really, is the way that we were going. And so there was a couple different things we did. We set up panels to select the sessions for each of the tracks. We have seven different tracks here at Summit. There were seven different independent panels selected. And those panels did the content. So as the submissions came in, so we had kind of a free call for papers. We had 267 submissions for the 84 available slots. And then each of the committees went through and selected the content that they thought they were most wanted to see. So they were able to get 12 sessions per track. In addition to that, we also ran a community voting process where the community could see all of the sessions and run votes for all of the sessions that were available. And we guarantee that each of the top seven community voter getters were guaranteed to slot in the conference. So the community really did choose the content and then provide the top content and provide all of the content for the session. So how did you guys, I want to know how do you stop people from gaming it because you got the Alpha Geeks out there. It's funny, yeah. Was there any chances of the gaming of the voting? We did watch for that. And we considered, do we need to do something to kind of prevent that? How Alpha Geeks will definitely do that? We definitely saw people get very clever about promoting their sessions, which in the end was the kind of thing we wanted. Quite frankly. It was one thing, but you know. I mean, manipulation is the other, right? It wasn't really, I don't think there was really a way to overly game it because you didn't have to register in order to vote. And each registered voter got a certain number of votes. So you couldn't automate it. It really did need to be a human. So no matter what, it's human in the loop. You couldn't really game it, but we had a great process. All of the top community vote getters have been very clever. And there was a lot of people you had to send away. So just talk about some of the sessions that were approved, the focus categories, and kind of there was a queue of people still wanting to submit stuff. Yeah, so I mean, we were lucky to have way more sessions. You know, as I think most technology conferences nowadays, way more sessions than you could possibly select. And that's always a tough, tough process because the line, particularly right at the, right at the things that didn't quite make it to things that did make it is really, really tough. And we took it from the chairs of each of the committees, their kind of stack ranked selection on what to put in. And so we really did divide the sessions evenly across each of the tracks, whether it was a technology track, a future of Hadoop track to the Hadoop and use track. So we've got all the different tracks that people were using or that people were selecting for. And really we took the track chairs recommendation and we did not defer from what the community and the community leaders said they wanted to see. And that's really what we went with.  So it's a great question. And the one thing we did do to try to, I think help the selection process was the track chairs that we nominated. So we just nominated these folks or, you know, sort of went to and asked them to be the track chair. We tried to select somebody who had knowledge in the particular domain area. So if it's Hadoop and operations, then we wanted to find somebody who would came from that background or had that kind of background such that they could select content that was, they were knowledgeable at the kind of content they were trying to select so that the content and the track that was built would be relevant for those kinds of people. Consequently, if you look at the different pieces of content, whether it's the future of Hadoop, whether it's the Hadoop in the enterprise, those different sessions, each one of them lines up very well to the audience that you're going to select. Consequently, we've got a very broad audience here because we go all the way from future of Hadoop, deep technical details about operating Hadoop, Hadoop in the enterprise, reference architectures for the ecosystem. So it's actually probably the broadest swath of the enterprise and the ecosystem that's been addressed at this conference, of any conference. Yeah, I mean, so you talk a little bit about, I love the analytics and the BI, so talk about that track a little bit and kind of what, because we think about big data and really delivering business value and it really is at that kind of application analytics layer. So talk a little bit about that track and what the focus is there. So the analytics and BI track, which is a really great track and there's a lot of really good content in there, is an important area, just like you said, Jeff, because that is, in some respects, where the rubber meets the road in terms of big data is people getting the value out from doing the analysis. So there's a nice blend of vendors in there, everything from vendors who are working directly within the ecosystem and have kind of spec-built applications for doing analytics to more traditional enterprise software vendors who are connecting to and providing value to attach to Hadoop as a data source for their system. So it's a very nice and mixed set of vendors and a set of ecosystem representation that are presenting in that track. So talk about the business model. We had your CEO on early, he was great. Rob's great guy. We had some good questions, easy questions. We had some uncomfortable questions around what everyone wants to know about, which is the community. And there's no real negative vibe right now within Apache. I mean, everyone pretty much agrees that it's growing like crazy. And there's plenty of beachhead for everybody. Pool's big enough for everybody. And that whole silly debate with CloudEra, Hortonworks is over, right? And it's pretty clear and talk to everyone you talk to, it's fine. But you've always had that comparison because CloudEra was the first one, venture-backed. You guys are venture-backed, both with Tier 1, BC. But what's going on around you guys is a bigger ecosystem. So how do you guys look at the market now? I mean, because you have to look at new dynamics.  And they're slower traditionally than the startups.  And it's kind of going on, right? And Arun was talking about some of the high availability features, age catalog, things you guys announced. So how do you as the VP of marketing balance that? Because the solutions are really the conversation, not the inner workings, which has been good. How do you balance all this? Because you're kind of constructing the venture. And the tech, at the same time, with the community. 100% open source. And then you got business relationships you've got to do with the marketplace. So you've got to balance that. So how do you do that? And I mean, I have a long history of kind of traditional enterprise marketing background. And then I've had four plus years of open source marketing background. So I think I have a nice blend of understanding what the enterprise wants and the B2B market and then the open source market and how that works. So I tend to run kind of a blended model of making sure that we are getting the awareness and evangelizing the technology as we need to, as it still needs to in the market and bringing the visibility to Hortonworks. And then also, from a company strategy standpoint, we're really targeting kind of, if you will, the enterprises that are on the other side of the chasm, right? We want the early majority of enterprises to feel comfortable with the technology. And we realize, in order to do that, the company's completely aligned around making Apache Dupe easy to use and easy to consume. So we're going to, you can see that in the release that we just had, the Hortonworks data platform, the kind of components we put in there are really designed for that, to make it so that the enterprises consume that. So from my standpoint, in terms of the messaging, I want to make sure that we are talking to those folks that are out there thinking about Hadoop, not quite sure what they want to do with it, but are looking for kind of the way to enter into that. And that also involves working with the ecosystem because we believe that the ecosystem is a key part of really what's going to make Apache Dupe a successful open source project. Yeah, we've got some good feedback. We've heard from some folks here in the Cube and also kind of back channels that the enterprise-ready messaging that you guys have with the products, not just messaging, this actual product, it's not just good for you guys, it's good for the app developers, right? So there's plenty of white space to work on. And so, as Doug Cutting says, the long list of things to do, and then everyone kind of is going, yeah, we got to do them, and it's a good list. It's not little things. There's big things. That's substantial. As real time becomes a key thing. So that's good. But enterprise-ready is hard. With Apache, it's okay, but with real time it is. So how are you guys onboarding those developers, also the developers key? What's your strategy for onboarding the developers? For onboarding developers? Well, I mean, so the first thing is making it easy to use and consume, right? Cause just get them to where they can get the tech in their hands and get to start to use that. We want to make sure that there's a broad set of open APIs that are industry standard inside of the platform. So making sure there's, for example, RESTful APIs into the file system. RESTful APIs into the metadata sharing functionality in each catalog. And really at every layer of the stack. So that developers are comfortable with common standard APIs so they can quickly build applications. And if I'm working on an existing application, I can easily see how to tie that into the infrastructure and embrace it in a much deeper level. Which means I'm going to be able to provide a much better end user experience, right? Because I can at some point abstract away the complexity of that there's this Hadoop thing running underneath it and still continue to push out a good user, either analytic experience or just general application experience. Well, you mentioned, you know, obviously you've got to make the technology easy to use and consume. And that's kind of a tools and technology perspective. But there's also that kind of skills gap and training the users. So, you know, I know Hortonworks is doing some good work there in terms of training and offering training. But tell us a little bit about kind of the interplay of the two. We have to kind of meet in the middle, it seems to me, where make the tools easier to use, but also you have to still build up the skillset. Yeah, right. You're right, Jeff. So we do offer training. We absolutely have Hortonworks University, which is offering developer and administrator training and working on a whole bunch of new classes. So the state of the market is that you still, there are so many people just at that basic blocking and tackling level, I'll call it, right? That they're just trying to figure out the basics of how do I do a MapReduce job?  And then, and it's really the kind of crawl and then walk and then run. And certainly the classes and the education strategy that we're trying to employ is to really move people along that path and move them across that. So that they can get to be fully operationalized, fully capable of developing applications so that they can move and take the infrastructure and build and make new solutions to your point about becoming about solutions to meet needs. I mean, we need to see more specific, spec-built apps like the Tresadas of the world and the Karma Sphere and the Data Mayors. And, you know, just we need to see more and more of those kinds of applications and tools that are addressing specific targets in the market. So yeah, I mean, in terms of, you know, meeting kind of halfway between the big, the tools easier to use and the training, but how much, you know, maybe we're not there yet. So how much is that kind of holding back your business? I mean, do you find that, hey, you know, there's just this whole area out here where we could potential business, but we just can't tackle it right now because the two just haven't met in the middle. Yeah, so I think there is definitely a need for skills. There are definitely, I don't know if it's holding back the business per se, I would say that those are growing at the same rate. And there is certainly a lot of need for education. If you just look at the, you know, indeed.com job graph, I mean, everybody's seen that, you know, how quickly the, or how much demand there is for Hadoop skills in terms of jobs. And that absolutely has to be leading because we need people out there with the skills in order to keep the tech moving forward. Now, to me, it's, and for us, it's a dual prong strategy because the more you can integrate with traditional vendors and you see the, the terror data is the world and others integrating deeply with the technology and able to abstract away that technology gap, then you can get a pull market because if I'm already comfortable with running a terror data warehouse and managing that, if the Hadoop infrastructure kind of runs as a plug-in or subservient to that, then, and it is abstracted away, I don't have to have as much new skill training, right? So we can't train enough data scientists in order to make the Hadoop market function. We have to enable the people with the existing skills to be able to leverage the technology with the skills they have or maybe only slightly augmented skills above what they have. So yeah, I mean, how, in terms of, you mentioned, we talked a little bit about your partners and how is that really, how do you kind of balance that relationship between partners like terror data and others? Where, in a lot of cases, they're complimentary approaches but potentially down the road, they could be not complimentary. How do you kind of balance those and is that something, is that just too far, too far into the future at this point? That horizon is way, way off for us. I mean, as you said with Doug and as we know very much, in order to make Hadoop easy to use and easy to consume, there's a long, long list. And if we can make that platform work and function, if we can get the entire ecosystem to rally around Apache Hadoop, then the market will function, that tide will lift all boats, the addressable market is tremendous, there's enough room for us and others. And so, we know if we make the market function, it'll be good for everybody and that's really what we're staying focused. So, one topic we haven't talked a lot about today is kind of like the data privacy and around security and things like that. Love to talk with you a little bit about that. We're seeing, we've seen some high profile data breaches out there in the press and some situations where big data has, I believe it was target, the target example, which a lot of people are familiar with, that was highlighted in New York Times. So, what are you doing, do you come up against that a lot in terms of potential customers saying, well, all right, this sounds great, we've got a lot of cool things we can do here with big data, but we've got to secure this. I mean, I can't risk a data breach in this day and age, it's just, the PR alone is going to kill us. So, good question, I would say we don't come up against it a lot, I think it depends on a per industry basis and a per use case basis. So, if I'm running back in infrastructure, which is refining data and analyzing models for a recommendation engine, which is the kind of customer facing up front piece, then I'm not going to have that as much. And that's, a lot of these cases for Hadoop are kind of background infrastructure and infrastructure is driving that. Now, as it moves closer to the four, then you start to see more of the request for data security and the requirements to drive that. And again, it's industry specific, so if they're dealing with customer data and have to load customer data in, then you end up seeing it more in those use cases, possibly in the government, healthcare obviously very well known, kind of security around health records and the like. So, it depends on the use case and the kind of data that they're loading. But I think still the addressable market for Hadoop in its state that it is, is still tremendous. And the security, like other things that are being addressed like HA and others, will get there and they'll get there sort of an adjust in time kind of developed way. John, my final question for you is, share with the folks out there that aren't here, because you guys did sell out, it's huge demand. What the vibe is because every time we do an event with whether it's Cloudera, the original Hadoop world that you were involved in, small, it's just massively grown since. It's a sell out upon sell out, H-based conference was a sell out, Strada was a sell out, Strada takes over Hadoop world, so you know it's a commercial business, it's for real. When you have a real business, the suits come in, right? So that one of the complaints with Strada was too many suits and not enough tech. Explain to the folks out there the vibe here and specifically the focus, so around how you kept it business-y but not business-y. You know what I'm saying? So part of that was, and the strategy was very deliberate to broaden the audience that could come and appreciate Hadoop and appreciate the Hadoop Summit and benefit from attending the conference. So we wanted to keep the core roots, Hadoop summits always had the core roots of a developer conference, lots of techy sessions going on. We wanted to maintain that but add a flavor of the business track, the Hadoop and use, Hadoop and the enterprise pieces. So the way we helped guide that process was really just in defining those seven tracks and saying, look, here's the kind of content we want to have, stay heavy with tech, make sure that that is well represented to the core of what Hadoop Summit started five years ago. And that was specifically you heard from the community saying, let's keep it tech. Yeah, let's make sure, you know, we know thy audience, that's what's a lot of folks here, tech tracks, you know, we need to hear about the future of what's going on in the technology. I want to see code up on the slides.  And then, hey, I also want to hear more about how it's being used, right? I want to make sure that I- It's not so much business, that's use cases, right? That's more path to the market. Yeah, that's right. It's like, just validation that there's a market there. Not so much- It's being used for real workloads and to solve real problems and provide real value in the enterprise. With a technical context. That's what we've heard. Often does, yeah. So that's what we've heard here. So, great event. Thanks for having us. Thank you. I know you arranged to have us bring the cube here and let us have space here. Wouldn't have a conversation with you guys. We do have some people walking behind us and there's a party going on behind us. So hopefully we can continue to broadcast. John Christ of the VP of Marketing at Hortonworks. Congratulations. Hortonworks is on a tear. Like Cloudera in their space. The startups are growing up in front of our eyes and maturing as well as the whole marketplace. So, congratulations. We'll be right back with our next guest here inside the cube. So if you're an angle.tv productions right after this short break. Thank you.


Oh, and welcome to today's Wednesday webinar. My name is Tina Salzer, and this video is gonna be the first in a series of videos on seesaw, using seesaw in your classroom. Many of you have probably already heard the term seesaw and just may not be familiar with what it is. So seesaw is actually a digital portfolio tool that is, the free version works just fine, but there's also a paid version. But basically it's a place to collect not only digital artifacts, but physical artifacts as well. For instance, a student could take a picture of an art project that they created, upload it into seesaw and record their voice over that art project explaining what it is. It's also a place where a student can create and upload their own artifacts into their portfolio. So the student has the ownership of their own portfolio and what goes in there and knowing that their parents are gonna see what's in there. So hopefully it makes them try a little bit harder as well. But it's also a great parent communication tool. You as the teacher can invite the parents to join their student's portfolio in your seesaw class so that when the student uploads an artifact, their parent gets only their feed for what they've uploaded as soon as the teacher accepts the upload. And it's a great tool to use during conferences for parents to go through their student's portfolio with them. And also it's a great communication tool for the teacher to the parents. Say for instance, at the end of the day, if the teacher posts what the students were working on for the day, the parent would get that post on their seesaw account as well. And if your children are like my daughters and you ask them how their day was and everything was fine and good, but you can't get any details out of them. Well, with this communication tool, the teacher could post what they were working on for the day and you could follow through on that at home. So let's go ahead and jump into and take a look at seesaw here. Okay, now let's take a look at seesaw and some of the things that it has to offer for you and your students. First of all, when I log into my account, I should see, I see my name up here and then underneath my name actually have two classes set up. For me, I have one practice class set up that I have my daughters that I practice with. And then I have another class that I use as a training class. You also can see your students right over here in the right hand side. And this plus sign is where you go at all of the different features. And so I'm gonna click on that because I wanna show you some of the things that you can upload into seesaw. First of all, you have the option to upload a photo. You could do a video recording. You could do a drawing. You could upload a file from your computer. You could type in a note, which I use for communicating with parents, or you could insert a link. So those are the options you have and I'm gonna show you what some of those look like here. So as an example, this is a note I typed in that I shared with everyone, which would include the student feed as well as the parents. And so basically what this does is it tells the parents what we focused on for the day. And I don't know if your preschooler is like my preschooler, but if I ask her at the end of the day what she did that day or what she learned that day, it's always, I don't know. So this way, the teachers can communicate that with the parents and the parents get that in their email and they show that there's an update to the Seesaw class and they can go in here and read that. And so when the kids get home for that day, you have a talking point and you can ask your children about what the teacher stated they did for the day. And that is one of the note features that I typed in on a note. Another feature, as I mentioned, is the drawing feature, which I used with my daughter. And basically what she did is I had her recreate a letter and then she drew a picture of something that started with that name and she recorded her voice telling about what that picture was. So I'll let you listen to that here. And so that's a great way to use the drawing feature. And here's another letter that she did to practice. And then this example I used with my other daughter, I pulled in a picture or an image and then I had her tell about the image. So that's another way you could use that. And then this example is actually my daughter, she drew a picture so you could use this for an art project and she created a video explaining what the art project is or explaining what is in the picture. And you can get the idea from there, but basically this is a great way to pull in two-dimensional projects or creations that you do within your classroom. Here's another example of how I used the note piece and then had my daughter read the text that I typed in. And I thought a great way that you could use this is within parent-teacher conferences, I could have her record her reading this sentence at the beginning of the year, then I could have her record it again at the same sense, at the middle of the year and then again at the end of the year so it could show her progress with learning words and learning how to read. So this is an example of the same type of thing. And again, you can pull in images, videos, pictures, just about anything you can think of and then you can apply that to your student's portfolios which at the end of or during parent-teacher conferences you could share just that student's portfolio. And when you invite the parents, the only item that the parents get is what their children share or what you share with everyone. So that is a good example of some of the things that you can see or how you can use CESA in your classroom. Now, to get started with CESA, you first have to create a class, excuse me, sign up and then create a class. So if you type in CESA.me, it will take you to this page and so you're gonna say sign up free.   I'm just using make believe account right now. So you put in your email and set your password. And then CESA is great at creating and hosting a lot of tutorials to walk you through each step as well. So as soon as you get into that class, it's gonna ask you to create a class name. And so I'm just gonna call this practice class one. Now, the important part is that if you continue to use these throughout the year in the class name, you may wanna include the year so that you don't get confused when you start incorporating this throughout the year. And then you also have to select the grade level for that class. And I'm just gonna choose third grade for now. And then you get to choose how the students can sign in. If your kids do not already know and have their email addresses and passwords that your district provides, the easiest way to do it is to have students scan a QR code. And then you get taken to an area where it asks you to enter your student name. If you already have a list, you can click here where it says paste a list of your students and you just copy and paste them in. I'm just going to enter a few students in here. And you might wanna think about how you enter them by name. Most of the time it's okay just to enter in my first name. And I'm just gonna add a few here so you can get the idea. And you can always go back, you can always go back and add more students in as you need to. Now it's creating my class for me. And once I get in there, it shows my name, it shows the class that I created. And then it assigns the students an icon to go with their name. So if I click here on manage students, I can change that icon to be one that they choose. But that's a way, for instance, how I allowed my daughter to choose the cow as her icon. So she always knew that she selected the cow when she uploaded images. Now I wanna show you how you can go into your classes and manage different settings within the class. You can manage the name of the class or you can change the name of the class. You could change the grade level. You could also invite other teachers to your class and to have access to your class. The students, you can share how the device or how the class is shared. You could share it based on class code. You could share it, and this says share devices. You can base it on just one-to-one devices with a class code. Or if your students are older and already have email accounts, you can share it out via their email accounts. You could also easily add additional students right here. And when you add the students, you get to add the characters if you chose the lower grade levels so that they can easily identify who is theirs. You can set if the students can like other students' posts and you can set if they can or cannot comment on their other students' posts.  This I have turned on because anything that is uploaded into Seesaw requires that I approve it first before it gets posted directly online. That's a great tool because that way you can make sure the right students have posted the right information and have put everything in the appropriate place. You can turn this on to allow students to edit their artifacts after they have uploaded them. This is where you can allow parent access. And if you click where it says invite parents, it will give you a handout for each parent in your student's class. So each parent gets a unique QR code or address to link to their account that is only specific to their students. This, if I click on this, if I had sent out parent approval to join the class, this would tell me if there is any that have not accepted. This is where you can also shut off or turn on parent likes and parent commenting as well as the sharing. You can enable a class blog where students and you could blog right on Seesaw. Within Seesaw, you can also have folders. And so I created folders in order to organize the artifacts for me. I created for Sawyer and for the animal pictures, there's animals and sounds, art projects, messages from me, and this is where Eden was posting the work on her name. And then of course reading and you could do math or any curriculum area you choose. These options, we can talk about a little bit later, there are more advanced options and things that you can do. But that is how you can organize and manage each of your classes and set separate permissions for each one if you choose. This is the whole class list if you click here. You get the calendar of events if you post something in there. And this would be where you would see your blog if you have that turned on. Thank you for watching today's Wednesday webinar. In the next Seesaw webinar, we will be covering the topics of getting students signed into your Seesaw account, what to do before inviting parents, inviting parents to join their students Seesaw feed, and finally some frequently asked questions. So see you next time.