Well, hello and welcome again to another OpenShift Commons briefing. This time we're going to be talking with Paul Murray again. He's one of the leads for the Kubernetes SIG on the service catalog work and we've got a release candidate going out that he's going to give us an update on and it's going to go along today. So ask your questions in the chat. We're going to try and do a Q&A at the end and hopefully we'll then in a secondary session later this week do some demos. But today there's so much detail we're going to run quite a bit of time. So please indulge us and Paul, why don't you introduce yourself and we'll just kick it right off. All right.  I'm Paul Murray. I lead the service catalog effort at Red Hat and I'm one of the SIG leads in the Kubernetes community for a service catalog and I'm on the Open Service Broker API PMC. And today we're going to be talking about the Kubernetes service catalog, both kind of an overview and refresher for people that haven't already seen this concept and are familiar with these things. And then also talking about much to my delight, the initial beta release, which we have just done in the last couple of weeks, the upstream service catalog and what that means for OpenShip 3.7. So we're going to start off just talking about an overview of OpenService Broker API, which I see I misspelled on the slide here, hooray. And then we're going to talk through the service catalog API in Kubernetes, what the key concepts are, what the main resources are and how they work together. And then we're going to see a little bit of service catalog in action in OpenShip 3.7. So the OpenService Broker API exists to fill this gap where users and applications need access to services and resources. And there are a number of different ways, both in terms of process in your organization and then also in terms of technology used to provision and manage those things that if you have any experience working in a large organization, like a large company, you're probably familiar with this situation where you need a database created, for example. And you have to create at least one help desk ticket. And sometimes you might have to create a number of different help desk tickets for different aspects of that process. And talk to a bunch of different parties to get these resources allocated for you. And then at the end, once everything is done, you get some information about how to use those things, like a connection string or credentials if we're talking about a database as an example. And those might come to you via email, they might come to you via someone writing it on a posted note, or there are a number of different ways that you might get that information given to you in your organization. So the value proposition of the OpenService Broker API and Kubernetes Service Catalog is that the service catalog provides a central place for you and other users in your organization to request new instances of particular capabilities or services and also insulates you from the process around doing those things and the technologies in use to actually do them. Which is important to me as a developer because if I just want to get a database created for myself or my team, I personally would rather not know that there had to be like a bunch of different tickets created for it. I don't want to track communication with different parties and I definitely don't want a posted note handed to me at the end that tells me how to use this. So the service catalog is meant to centralize these things and OpenService Broker API is meant to define the interactions between the catalog or platform and the entities that actually provide those services, which we call service brokers. So to just double down on that because this is an important concept that I found there to be some confusion on in the Kubernetes community and OpenService Broker API community. Let me just repeat that again. So the OpenService Broker API defines an HTTP interface between a platform and the entities that provide services, which we call service brokers. A service broker is the component of a service that implements the OpenService Broker API. So you'll probably hear me say that again. If it gets repetitive, that is excellent and my goal for people to be so familiar and so deeply internalize this concept that it gets boring to them. So let's talk a little bit about this. Now you're the user. You're using the service catalog and the service catalog is managing communication between one or more brokers. And the brokers are the things that actually provide the services. Service catalog is how you interact with them. And to a great degree shields you from even actually having to understand the OpenService Broker API. To just reiterate that the OpenService Broker API, generally you do not have to implement that like program to that directly. You'll program to the platform what interface it gives to you to use it. In this case, it's the Kubernetes service catalog. So you're programming or interacting with the service catalog and the service catalog is the thing that actually communicates with the brokers. So a little history lesson on OpenService Broker API. There are a number of different vendors that are present at the OpenService Broker API table in the working group. Obviously Red Hat. There's also probably fairly obviously a pivotal presence because of the origin of the OpenService Broker API, which we'll talk a little bit about. But Google, IBM, Fujitsu, SAP and actually since I originally created this slide several months ago, there have been a number of other vendors that have started having folks attend like Microsoft, Atlassian occasionally. And so there's a number of different vendors and the pool of vendors that are interested in this is growing, which I think is a good bellwether for us as folks that are implementing the API and Kubernetes and the community around it that it seems like adoption is going up. So like I said, OpenService Broker API originated as the Cloud Foundry Service Broker API in 2011. And the recent history of this API is that in mid 2016, the Cloud Foundry folks were having users and users of Cloud Foundry coming to them and saying, we really like the Service Broker concept. We want to use this in other platforms that aren't Cloud Foundry. Obviously probably the biggest gorilla in the room in that scenario is Kubernetes, which has become extremely popular over the last three years. So in 2016, we formed a new working group for OpenService Broker API and later on December 2016 announced that the Cloud Foundry Service Broker API had become OpenService Broker API. And then this year we've had two really important releases for us, especially in the Kubernetes community because they introduced new concepts into the OpenService Broker API that both generalize the API beyond Cloud Foundry. It's Cloud Foundry origins and add new concepts that are important to everybody, both Kubernetes and users of Cloud Foundry because they enhance the capabilities of the API. So in June 2017, we made our first significant change to OpenService Broker API and introduced this context profile concept, which is sort of the first thing that began the decoupling of the API from Cloud Foundry specific concepts. And context profile is a way for a platform to send coordinates for their own platform, in our case Kubernetes, about the context for an API request. And we'll talk a little bit more about this, but it's very important to us for Kubernetes because we were able to begin sending the Kubernetes namespace instead of using the buckets for Cloud Foundry coordinates, which are called Oregon space. So later in September 2017, we had another really significant release where the three top things that are interesting and important to us are that Service Brokers can now communicate parameter schemas for their services that they offer. So what this means is that there's always been parameters support for services, so you can specify particular parameters when you request that a service is created, but you really had to know about those things before you did that. The parameter scheme is important because it allows the Service Broker itself to communicate to a platform that integrates with it what parameters it expects for certain operations. So you can create a user interface as a platform author that tells users what parameters they can set. So the next one is the originating identity. And what this is is a way for a platform to send information to a broker for a particular operation that describes the actual user of the platform that's creating or requesting a particular operation. So this is really important to us, especially for use cases where brokers provision services into Kubernetes, which you're going to see we have a few different brokers at Red Hat that we've developed that actually do this. Because it allows the broker to do things like make checks about whether a user is allowed to do something and to make those requests on behalf of the user. So this is important to us because it allows us to use the user's quota and RBAC rules in Kubernetes to check and see as a user do I have permission to do this and then also to allocate those resources against my quota. And then finally, we added in a kind of roundabout fashion support for additional auth flavors in the API. Before this 2.13 release, the only official auth method in the API was basic auth. And there are a number of significantly more secure flavors of authentication that are available to us. So we use an OpenShift already that you might be familiar with, for example, token based authentication, which you get as part of getting a Kubernetes or OpenShift service account. So this is another really important one to us at Red Hat because it allows us to use Kubernetes service accounts and their tokens to secure brokers, which is really, really important. So I have a timeline here that I've already kind of talked through this. It's mostly here for folks that might want to dig into some of these details. I'll go through it again just for completeness and also because it's kind of interesting to me. So you can see that the Cloud Foundry Service Broker API began in 2011 at VMware and initially there was just support for five fixed types of services. They're MySQL, Postgres, RabbitMQ, MongoDB, and Redis. And this is really interesting to me having worked on three different iterations of OpenShift because it kind of parallels the evolution of OpenShift. In OpenShift v1, we had a very fixed set of different cartridges that you could use. And over the progression from v2 and v3, we added support for users to make their own cartridges, which parallels what happened in 2013 in Cloud Foundry Service Broker API where they released v2. And there's now a very clean abstraction between the platform and service implementation similar to how we had a kind of concurrent evolution in OpenShift, where we moved from fixed types of things that you could do to more generalized things and especially the ability to add new things as a user. So then in 2015, they added asynchronous provisioning to the Cloud Foundry Service Broker API. And what this means is that the API was then able to describe to platforms that they've accepted a request to make a new service and the platform should call them back periodically. Instead of just having the service broker have to do the work within the lifespan of a single HTTP call, this is really powerful because it lets service brokers do a lot more work and opens up the possibility to create services that require a significant amount of time to stand up. So then as I've already talked about in 2016, it was renamed to Open Service Broker API. And then in 2017, we've had a couple of releases that add a lot of things that we're interested in in the Kubernetes community and in Red Hat and begin decoupling the API from Cloud Foundry specific concepts. So that brings us to the centerpiece of this briefing, which is the Kubernetes Service Catalog. And you probably already have an idea of what this is, even if you haven't seen the Kubernetes Service Catalog before because of what I've already talked to. But just to put a fine point on it, the Kubernetes Service Catalog is an integration between Kubernetes and brokers that implement the Open Service Broker API. Another little history lesson here, we formed a SIG in the Kubernetes community around this area in 2016 in September. And later in October 2016, we created the incubator repository. There's a link there. It's in the Kubernetes incubator or it's called Service Catalog. And that was a really interesting and eye-opening experience to me for a number of different reasons that I'll probably sprinkle in to the rest of this presentation. But one of the foremost things that I'll mention, I'll definitely mention this again, is that the Service Catalog is really one of the first proving out of the concept of making an extension to Kubernetes, which has an architecture similar to Kubernetes itself. And something that was a challenge for us in this group is that the SIG originally was populated with folks that did not have a deep background on Kubernetes. So it was a really eye-opening experience trying to explain and evangelize the concepts that we wanted to converge on at Red Hat with this Kubernetes-like architecture and API aggregator that I'll be talking about in a moment. So in March 2017, we released our first alpha release of the Service Catalog, the first of, if I remember correctly, 23 alpha releases of Service Catalog. And this was a really big hump for us to get over because we had converged on this architecture that we were proving out and had the basics of the integration between Kubernetes and Open Service Broker API implemented. It wasn't complete, but it was enough for folks to use and play around with. And we actually released a later alpha version in OpenShift 3.6. 3.6 is a tech preview feature with, which I'm sure that some of you have used in detail and others have maybe played around with. Fast forward to October 2017, we released our first beta release of Service Catalog, and this is a really important milestone in the Kubernetes community because when you call something beta, it means that you have to maintain API backward compatibility with it. And that's important both for users in the sense that a lot of users won't touch things that are alpha because it could be quicksand, right, like it could change underneath you. And that's what the purpose of alpha is, is to designate those things that are still really in the beginning of their development as being so. But it also kind of means that people with a high tolerance for change are going to be most interested in those things. So beta is very significant to us at Red Hat also because it means that we can take off the tech preview designation in OpenShift 3.7 for Service Catalog, which is important for us and it's important for users because users know that there's going to be backward compatibility with future API changes. So the primary contributors are players that I've already kind of mentioned a little bit. Red Hat obviously is one of the main contributors of code to this repository. And Google, Elassian, Microsoft, and IBM have also made contributions. So I hope if you're watching this and you're somebody that's interested in this, I will just take advantage of the fact that I have the bully pulpit at the moment and say I would love to have new contributions and contributors from other organizations. We try to be a friendly bunch in the SIG and it's also a good way to learn about Kubernetes without some of the overload effect that you might have if you go and try to look at the main Kubernetes repository. It's a lot smaller than Kubernetes Kubernetes. So alpha to beta, what changed? A lot of things it turns out. From a feature standpoint, we now have support for token based authentication and enhanced TLS support for communication with service brokers, which is important from a security standpoint. We now have support for that originating identity feature. That's in the open service broker API now, which is important, especially to us at Red Hat, having a lot of broker provision resources back into Kubernetes and OpenShift. And then finally, we've completed the implementation of open service broker API and Kubernetes by adding support for plan and parameter updates for instances of services. So if I make a service instance, and that service supports plan updates like going from a bronze plan to a gold plan, I can now do that in the service catalog. And I can also change the parameters of an instance that I've already provisioned, which is really important to users for a number of different reasons. From an API standpoint, the high notes are that the catalog API works with the Kubernetes API aggregator just to revisit that concept, and we'll revisit it again. But to put a fine point on for now, the API aggregator is a capability that's built into the main Kubernetes API server that allows you as a cluster operator to register new API servers that provide new API groups and resources with Kubernetes and allow your users to use those things, just like they were part of the main Kubernetes API server, which is a really fundamental capability to the story that we expect to be dominant for how you extend Kubernetes in the future. And we'll talk a little bit more about this once we get into the API details. We've also had significant refinement of the API resources in terms of what the Kubernetes way of doing things is. I think that this will be pretty clear what I'm referring to once we start looking at examples of these resources. But we spent a very significant amount of time talking to other SIGs in the Kubernetes community, like SIG API machinery, SIG auth, and SIG architecture about how do we make this API, the service catalog API in Kubernetes look and feel and work just like any other API that's part of the main Kubernetes repository. So this is kind of a sub bullet this next thing of refinement of the API, but the resource status for the main API resources that users interact with now has very detailed information about completed and in progress operations. That the API is performing or that the service catalog is performing against the broker. There were some unique challenges that we had to get over due to the different styles of Kubernetes APIs and the open service broker API. But the end result is that as a user, you can now take a look at one of your service instances and get a much better idea of what is actually happening currently and what the last thing to complete that the broker knows about is, which gives you a much better idea on the ground of exactly how the thing works, which is very important and also what's happening currently. And then last but certainly not least, we've vastly improved the error handling in the service catalog so we can not correctly handle operations that time out or fail. And we can also correctly handle corner cases like if a user creates a new service instance and it's being provisioned. And then while it's being provisioned, they deleted will handle that correctly now where that was something that wasn't especially mature during the early alpha releases. So service catalog API concepts. Here's where we get into the nitty gritty of the nitty gritty details of exactly what this API looks like in Kubernetes. We're going to just talk first, very briefly about the operations that are part of the open service broker API, because the API resources we're going to talk about mirror these things to a very great degree. So open service broker provides five fundamental operations. A broker can tell you which services it offers. And then there's a provision operation where a new instance of a service is created and new resources are allocated. There's a bind operation that creates resources to allow applications to communicate with an instance of a service. And then those last two have symmetrical operations where they get deleted. So when you delete a binding, it's called unbind where the binding is removed. And when you delete in service instance is called deprovisioning, where the resources associated with that service instance are deallocated, and the instance is deleted. When we talk about these concepts in Kubernetes, let's just put a very specific fine point on these things. A service broker is something that manages a set of capabilities, which we call services. A service class is a particular capability managed by a service broker. And the canonical example that most people can relate to about this is a service class might be a database as a service. Service classes have plans which are a specific tier or offering of that service. So for example, our database as a service might offer a free tier where maybe you get a table space in a multi-tenant database where your data is stored alongside other folks. You might have acceptable performance characteristics for development. And there might also be like a medium or a gold tier that you had to pay for potentially where you get maybe get a dedicated database with nobody else's data living in it and better IOPS performance. So plans are basically levels or tiers of a service. Then a service instance is an instantiation of a particular service's capability. The example for that is when I want to provision the database as a service, I get my database that I can use as a result of that. And then a service binding is a relationship between a service instance and an application. So following our database as a service example, a binding would be credentials created in the database that I can use. And then the output of that to me is a secret where that stores those credentials that I can use in my Kubernetes pods. And application for the purposes of this discussion is just code that will access or consume a service. So there's no limit on which types of constructs and Kubernetes can consume bindings. Basically, anything that runs as a pod, whether that's like a replica set or deployment, job, et cetera, can use the secrets that hold credentials for bindings. And we just call those things applications for simplicity when we talk about this concept of the service catalog. So as I've kind of hinted at before, Service Catalog has an architecture that's very similar to Kubernetes itself. There's a Service Catalog API server. And the API server is the entity that exposes the rest operations for these different API resources that we're going to talk about and persist those things into a data store, which is at CD. The API server is backed by a controller that is watching the API server and responding to events that the API server sends out about the resources that it stores. The controller is the entity that actually implements the behaviors of the Service Catalog API. And in this case, the controller is doing the work of talking and communicating to the brokers and saying to the broker, we want to make a provision a new instance. We want to make a new binding to this instance. And we're going to see a little bit more about this later in the deck. Here's a pictorial representation. And you can see on the left hand side of the screen, this box for the CLI, you can think of this as just being any client right like it might be a user using the CLI. It might be a program that's programming against the Service Catalog API. It might be the OpenShift console, but clients speak to the API. And for simplicity's sake in this picture, we've omitted the API aggregator, but they speak to the API using going through the API aggregator. The Service Catalog controller has established watches on the API server and implements the behavior of talking to the brokers that are registered into the catalog. And then is persisting changes back into the Service Catalog API server, for example, to update the status of the different resources, and also persisting information about bindings into the Kubernetes API using a secret resource. So when we talk about the API resources of the Service Catalog API, there are five of them. And if you saw our last Commons briefing on the Service Catalog, you noticed that this number climbed up by one, which I will talk about. But there are basically three resources that are mostly for cluster operators, and two resources that end users use. The ones for operators are the cluster service broker resource, cluster service class, and cluster service plan. These are cluster scoped, meaning they live outside of a namespace. And these are for cluster operators to use to register a broker in, and then register a broker in the catalog. And then the controller creates these cluster service class and cluster service plan resources to model the services that are in the catalog endpoint that they get back from the broker. The service instance and service binding resources are how the user creates new instances and bindings to service instances. Let's drill into cluster service broker. This resource represents a particular broker that the Service Catalog should show services and plans from. You can see that this resource is spec, and I think, yeah, you should be able to see my mouse, has a URL where the catalog should contact that broker. And then also has auth information where you can reference a secret that has an authentication token to communicate and authenticate to that broker. Now, I didn't have space to show it on this slide, but you can also give a particular CA bundle that you want to verify the broker's TLS. And you can also specify basic authentication using a secret that holds a username and password if you need to use an existing broker that only handles basic auth. But this is what the cluster operator uses to register a new broker into the catalog. So let's look at a picture. And this is a little out of date, but I think that it will still be very, very clear just the resource names have changed and there's a new resource that isn't captured on here, which I'll talk about. So in step one, the cluster operator makes a broker cluster service broker resource and creates it in the Service Catalog API server. The catalog controller gets an event saying that that new cluster service broker resource was added. It goes and invokes this catalog endpoint at the actual broker, which is running either, you know, potentially in the same cluster, Kubernetes cluster or somewhere out on the internet. And it gets back a payload from the broker that contains information about services that broker offers in their plans. So the Service Catalog controller transforms that information into the cluster service class and cluster service plan resources and persists those back into the service catalog API server. So at the end of this flow, now there's a broker resource and there's cluster service classes and cluster service plans that describe the services that users can use from this broker. So let's look at cluster service class and cluster service plan really quick. The cluster service class, as I've said, represents a particular offering in the catalog. And one thing that you will notice if you use the alpha version of the API is that the name here is actually an ID. You'll also notice down here that we have these external ID and external name fields in the spec. And the reason for this, well, first the difference that you'll notice in coming going from the alpha version of the API is that the name of this is not currently human readable. And also that the plan information is now in a separate resource. So just to talk through that really quickly, we had to adopt this naming strategy because the open service broker names of services are actually mutable and Kubernetes names of resources are not mutable. There is a lot of design time that we spent talking about the best way to handle this. And the simplest thing that we could do in the SIG and incubator repo to hit our goals for getting an alpha or sorry, getting a beta release out is to use the immutable IDs from open service broker API for now. But we let users specify using the human readable names, what service and plan they want. In the future, we'll probably adopt or add a naming strategy to the service catalog that uses the readable names and handles the name changes. But unfortunately, we just didn't have time to do this and still hit the targets that were important to the folks working in the incubator repo. So let's take a look also at the, I'm sorry, I skipped over something. So last thing on the slide, the spec plan updateable field describes whether instances created of the service can change plans. Not every plan supports this or I'm sorry, not every service supports this, but some services do support changing from like a bronze plan to a gold plan. Excuse me. So looking at cluster service plan. This represents a particular plan. And this is a plan for the example cluster service class that we just showed. It has a description and it's also got these external ID and external name fields and similar situation with these, we had to use open service broker ID as the name of these resources for now, because the names can change. And there's also you'll see on here in the spec of free field that indicates whether there's a monetary cost for this plan. So that kind of rounds out the resources that are created by the cluster operator and then the catalog in response to the cluster service broker resource being created. Let's talk about the service instance resource, which is the central resource that users interact with to create new instances of these services. So the first thing that I want to point out here is that the service instance you'll notice has a namespace. So service instance and service binding are namespace scope. The cluster resources are cluster scoped. In the future, we will probably have namespaced versions of the service broker service service class in service plan resources so that users can set up a broker just in their namespace without exposing. That broker to the rest of the cluster or having to have permission to create the cluster level brokers. So let's dig into this thing. As I said, users use the human readable names to specify what service and plan they want to make an instance of. So you'll notice here there's a field of a spec called cluster service class external name. Its value is user provided service and there's another one down here called cluster service plan external name and its value is default. So when the user created this resource, they just fill out those fields. They say the user provided service and the default plan and the service catalog controller resolves those to the actual Kubernetes names and sets these reference fields so that it can translate between what the user wants and what are the coordinates of those things. And then you'll see below that there's an external ID field. This is generated by the service catalog API server and it's the ID of the service instance that's actually used to communicate with the open service broker API. And then below that you'll see that there's a parameters field and you can specify parameters either in line like we've done here and I realize now that the credentials bucket that's part of the parameters. That's very poorly named. You should not put credentials in line into a service instance. You should instead reference them from a secret, which I didn't have the space to show here. But that is another thing that you can do, which we always put parameters into a secret when you use the open ship console so that sensitive information doesn't go into a resource that doesn't have the right protections on it. But let's talk about before we get too lost in the details, let's talk about the workflow when I create this resource. So as a user, I create a new service instance resource in the API server. It gets that ID generated for it. It gets the references resolved to the actual service class and plan and I'm sorry, gets the ID generated. The controller gets an event saying that the service instance was created. It resolves the service class and service plan and then it talks to the broker and says we want to provision a new service instance with this ID of this service in this plan. The broker then goes and does the work to allocate that resource and it might use the old synchronous style where maybe the service broker can just do this work and one HTTP call, or it might tell the catalog controller, hey, I've accepted your request, call me back and see if I'm done yet and keep calling me back until I'm done. And service catalog controller handles that coordination and ultimately updates the status of the service instance to let the user know what happened and reflect on the service instance status, what parameters the broker knows about, what plan the broker knows about, stuff like that, so that the user understands what state the broker knows about for that service instance. These are a couple slides about asynchronous provision. I was on this so that you have a chance watching the video to to drill into the details here. I'm running a little short on time. But this slide is fairly self explanatory. So I'm going to skip over it and go to service binding. So a binding is a relationship between an application in a service instance. And you'll notice this resource is also namespaced. It's got that external ID field just like service instance does that's generated. And it's the ID that is used during communication via open service broker API to refer to this resource and Kubernetes. The other parts of its back are a reference to the instance that the binding is to. Currently you can just refer to a service instance that is in your namespace, but in the future it's very likely that we will have the ability for you to make a binding to a service instance that's in another namespace that you've been granted access to. And then finally, the last part of the spec is a secret of the name of a secret to inject the binding credentials for this service binding into and that secret is created by the service catalog controller and will ultimately hold the credentials for that service instance. So let's take a look at our picture again. Consumer creates a new service binding in the API server controller detects that new binding. It talks to the service broker that offers that service and says, let's make a new binding. The broker does the work to do that and hands credentials back to the service catalog controller and then the catalog controller creates a Kubernetes secret with the binding credentials and updates the service binding resource status to show what happened to it. When you want to remove these things, it's very easy. You just delete the Kubernetes resources that correspond to the thing that you want to remove. So if you want to unbind you delete the service binding that you want to get rid of and the service catalog controller does the same kind of thing where it tells the broker to unbind a particular binding. And when you want to deprovision an instance of a service, you do the same thing. You delete the service instance and catalog controller handles talking to the broker about that. Now one thing that I'll mention is if you delete a service instance that still has bindings, you have to delete those bindings before the controller will deprovision the instance. If you do that, you'll see a piece of status information that says, I can't deprovision this yet because there are still active bindings. You have to go in and clean up the bindings before we'll send the deprovision. So I'm going to skip over these next two slides. I'm going to just pause on them for a little bit. But since we're running low on time and they're pretty simple concepts, we'll just pause on them so you can see them in the video. Now let's talk about service catalog and OpenShift 37. So in OpenShift 36, as I said, we shipped service catalog with a tech preview qualification. That is not present anymore. The service catalog will be enabled by default in new OpenShift 37 clusters. And we have a number of different brokers that we've developed at Red Hat, like the template service broker that uses OpenShift templates, Ansible Service Broker, which leverages Ansible Playbook bundles to automate the creation of complex services, and then the on-mass service broker that provides messaging as a service type services. What's really exciting to me is there's been a lot of work in the console to enhance the service catalog experience, so you get really nice icons for services now if the broker communicates what icon to use back to you. This is pretty central part of the landing page, and there's been a lot of work to incorporate all of the API constructions that I referred to about status into the console to reflect things back to users about what is going on with a service that they've provisioned. So let's take a look at some screenshots here of what it's like to provision a service in the OpenShift console. So say that we're provisioning a Postgres instance from the Ansible, you can see what image dependencies it's got, and you can click through then and choose a plan. Once you choose that plan, you can provide some parameters, and these are driven off of the parameter schema that I referred to earlier in the Open Service Broker API. So just to drive home exactly how important that is, that allows us to make a user interface that can tell users what knobs they have to set. So we're going to go ahead and pretend we click next here, and then we can create a new binding in our project to that service instance, and it will be created by the controller like we just discussed and contain the coordinates and credentials that we need to use that service in a pod somewhere. So I don't know about folks watching this call, but it's really awesome to me to think about all the different possibilities that this enables and makes easy to use via the OpenShift console. I'm really impressed with the work that Red Hat UXD and the OpenShift UI team has done for this stuff, really cool stuff. And that is basically the end of it. So there's some resources here in the slides for Open Service Broker API and the service catalog repository and information about the SIG. I'm going to switch back to BlueJeans now to see, I see things in the chat. There's a couple of questions, and mostly I think if you go back to the EnMass question here, one was asking that whether the EnMass service broker was going to be available in the launch of OpenShift 3.7, and I believe so, but I was wondering you're sitting in the middle of the engineering team, so maybe you know better. I'm going to have to double check on exactly what's going to be available in 3.7 for EnMass. We are going to record a demo, probably tomorrow for this so that you can see it, and either in that demo or at some point in the blog post we can provide some information about that. Yeah, so we'll post the slides for this talk into a blog post and tomorrow or Friday we're going to record the demos of all the OpenShift 3.7 capabilities with the service broker and include that. Someone is asking if you can come to see this too, will APB catalog items potentially be part of 3.7? I believe the answer to that question is yes. I think there's a lot of yeses here. There's a lot of work that's gone into it, yeah, because it is right. So, because of the nature of having to set up this whole conversation, this session has run pretty long and I really do want to get the demos out there. I'm going to, I've asked Paul to record them separately from this and we will post those on blog.OpenShift.com and hopefully by the end of this week and we'll tweet that out and send it to the mailing list. As well, Paul is going to be with me and a whole bunch of other OpenShifters on August, December 5th in Austin, Texas, the day before coupon and talking about service broker and be there and available to answer questions as well. So, if you haven't registered yet for that event, please do so. It's going to be really a lot of interesting conversations with upstream project leads and people who are deploying OpenShift and so we hope to have you all there with us as well. That really brings us to the end of the hour. Paul did a great job given an overview and we will post this as soon as possible. And I will make an announcement on the mailing list as well and in social media. We'll probably record the demos live as well with a little Q&A. So, if you want to join us for that, I'll make that Eugene session available on the OpenShift Commons events calendar, which is at commons.OpenShift.org slash events.html. John's asking one last question, is it going to include AWS as well? That's a really good question, John. The AWS services are on a slightly different timeline that I don't have the specifics in front of me. But you'll definitely be hearing more about in the future. Diane, can I just, can I say one extra thing here before we sign off? I just want to thank you to everybody that might be watching that has contributed to the repository in some way, whether that's code or user feedback. That's really important to us and it's very sincerely appreciated. So thanks a lot for watching and thanks a lot for contributing. And to the AWS question, John, David Duncan from AWS will also be at the OpenShift Commons gathering and I'm pretty sure that's what he's going to be talking about. So please do join us there. There'll be a lot of good content that will get you up. So that's what we have and we'll sign off for now.


and welcome back to the Creative Life Show from the American Creativity Association's Austin Global Chapter. And we are produced by Think Tech Hawaii. I'm your host, Phyllis Beas. Joining me today is our guest, Diane Dean. Diane is a master certified coach, and she is a co-founder of this Austin Global Chapter of the ACA. Today we're talking about how to work into your brain. And we'll be looking at Diane's unique approach called the learner's learner's edge. So let's meet Diane. Aloha, Diane. Hello. Glad to have you today. And this learner's edge, could you give us an introduction into what that means? Well, I think that when we try to learn things and we aren't able to, we need some help. And so I discovered the edge, the way to get into my brain and learn better. And I was able to frame it that way so that people don't think that we're just making something up. It's really a phrase that we use. I've got the edge on that. You know, I can do it better. And so it was sort of a positive frame for helping people learn and made you learn at the time. Okay, okay, that's helpful.  I'm going to let the audience know that in this half hour, we're going to cover five modalities that you become an expert at to help unlock creativity in people. One is a horse course. One is psychotherapy. Another is neural linguistic programming, which many may recognize as NLP. Another is academic coaching. And then another area is corporate learning and professional development in business and the corporate area. So we have a lot for you today. And Diane, the intriguing one, of course, is that horse course. And we've been blessed with a short video of a little bit that see you in the field with this. So if mine could show it to us, let's start with that. In the early 90s, I was teaching. I was teaching communication to people. I was also riding. And so I was noticing how similar some of the things I was teaching for good communication were the same things we had to do with the horses. So I said, how can I use this? How can I play with horses all day and get paid to do it? And to teach people through horses. People and teams get to experience how their energy affects others. And their feedback comes from a 1000 pound non-judgmental animal. We make each course for each team unique. We start with getting to understand oneself, getting to understand horses, how we're similar, and some differences. It's amazing how good it is to interact with the horses and become aware of what's going on inside of you. My ultimate goal for the program is for people to understand themselves through horses. Okay, well, I wish you were out there right now. The horses. And when we were first prepping for this show, I thought of you as a horse whisper. And you said, no, that's not quite what I'm trying to do here. And I thought that your explanation of how, because we've all heard about horse whispers, right? No, that's different from this course. Could you explain a little about that? The way I see it, the horse whispers, there are many, are the ones who have a way with horses and really, quote unquote, speak their language so that they can train them, manage them with less effort, no bullying, none of that. That's the word whisper. So when we do the horse horse, we're really blending what we know about how horses take us in, think about us. And we learn things about ourselves that pop up from our hearts and our brains and help us learn about ourselves. Okay, so how does this alchemy work? We get on the horse. Oh, it's all in the ground. We don't get on the horse. Nobody can come to the horse horse. Okay, about moving them around, playing with them, we play games, we get them to follow us, we get them to go over steps of things, by being in sync with them, we have to get aligned with them. And we have to pay attention to the small details that they give us. And people do that too, they give us small details, but most of us don't pay attention. I learned all about that with the NLP you mentioned earlier, modeling how people do communicate. Well, horses communicate as well. Okay, well, you told me about a man that was in one of your group training, he was a leader himself. He is. I think that was a slide to put us in the outdoor room with you all. Right. Could you tell us about, I never heard the story on this. Right, I do tell you. I know, I'm curious. We were in groups of three. And so Michelle was working with three and I was working with three, but one at a time. So we invited John up, I invited John up, and gave him the instructions to, without using a lead rope, without using a stick or anything, other than heartfelt communication, to get an alignment with this horse and get it to follow him, walk with him around this round. And so when he came up, the horse moved way back instantly. It's like, uh, no.  And so he walked toward the horse again, the horse moved further away from him. He took a deep breath. John took a deep breath and said, you know what? I was feeling just like I used to when I'd compete with my twin brother.  And when he realized that he could maintain a more peaceful inner state, the horse relaxed and followed him. And it was amazing. He was so surprised and so surprised at what came to his mind and art, as well as how easily it worked when he got himself together. And leaders have to do that when they're managing people. That's what they're putting out. Yeah. He did see, I mean, the horse was really obvious. It took steps back. You know, your staff is not necessarily going to take a step back. And yes. And one of the things that I do teach is how to watch the smaller details that humans give off. Okay. And so that's again part of the NLP model. All right. Well, we want to talk about that. Do you, I think you have another slide to share with us today with one on one and what more playfulness with the horse and yeah, look at you and Liz or Liz and the horse. Liz and the horse and the people on the other side of the horse who were short. What are you doing there? You're drawing on the horse or we're doing two things. One is she's noticing what intimidates her. A lot of people are intimidated by horses. And can she manage that? She's a very, very powerful leader in her own right and has a very good business. And there's times when she needs a little more strength in her heart and her mind, you know, just to step out, especially in what often is a world of people who are running their own business. So they're all bosses, they're all owners. So the horse represents that for her in one way. So she was, you can see she's standing back a bit. Yeah, for the aunt and that that's when we took it because she's like, I don't know about this because I mean, people don't paint on horses. They don't know what's going to happen. And so it's a surprise that the horse just kind of relaxes and she could hear the horse releases breath and she started to get closer to him. And at the end was patting him and that sort of thing. And first it was just out there with the pen or the pencil or the pay brush is what it was. So she really enjoyed that. Yeah. Well, and just for the for those who don't work with horses, this is not at all unkind to the horse. It's like going to the do the carnival and getting face painting and we all laugh and watch it all. Absolutely right. Thank you for bringing that up. We don't do anything that's not kind to the horses. I mean, that's, that's just the way it's done these days in the world of playing with horses, we call it. Right. So does this do the, I mean, we're talking about unlocking our creativity, hacking into our green are the reports coming back to you and through I'm sure I'm sure you're replicating the model that do they have take away our haas from this feel learn more about themselves. All right. You know, I'm just to say how many times do you need to do this and what's different things and you have different things to learn. So what we do is we play games and then we process it in some of the workshops will have the right journals, you know, what came up for you and then they process it. And that's where I bring my original psychotherapy background into understanding what they're talking about. Because all my things that I do for creativity is layered on each other in my work. So psychotherapy and you were a psychotherapist, you went to school, you got it. Well, tell us about that.  So there's a me story here that I'm sensing into. Well, me story started a bit earlier than the horse did. The horse thing did. Because when I was wanting to go get my master's in psychology, I had been a poor learner. I flunked algebra twice. I flunked French. I was on scholastic probation my freshman year in college and I barely got out of college with a D plus because I was a graduating senior. However, I just didn't know how to hack my brain to speak that language. Yeah, I didn't know how it worked. So I went to a therapist therapist was learning one of the first people learning NLP. And he taught me the layers that I could access that make people, quote unquote, smart. Some of them do it naturally. I did not. My older brother never brought him a book and made all A's because he had the pattern of smart people that was natural, that's more natural. Okay, so I can just to just stop for one second. So we're talking about a big word. Yeah. Because you said pattern. I know programming is in the name of this of this modality. Neuro linguistic programming. Hey, don't mind if I haven't interrupted your thought. No, if you could, what is this thing that the therapist brought forward for you that put you back on a par with your brother doing it, you know, having these patterns automatically, you have to know they're there. And one of the patterns are there. And so one of the things that created NLP was several people are two in particular, Richard Baller and John Grinder started modeling people who were excellent communicators, or excellent therapists, or excellent anything. And they started looking at their patterns long before neuroscience came along recently as said, Yeah, this is the way it works. So what they the simple part of it is, we have lots of different ways that we remember that we think that we create in our minds. And we have different levels of consciousness of them. So my brother was not conscious that he made pictures in his head and could remember anything. I didn't make pictures in my head, because I was usually talking to myself and criticizing myself and worrying myself. And so I actually got in my own way. And the interesting thing for me was that I didn't know what I didn't know. And in LP, this therapist was the one that helped me start to understand how to approach learning, thinking, and got me even public speaking, because I couldn't do public speaking if I couldn't remember what I was talking about. Right. So, yeah.  So I imagine there's learning about the brain and how the brain works and totally. And then you became self aware that you were the self top was was just blanketing the air with a distraction, a real bad distraction in between you and your incoming. So you have incoming cross I know and create creativity work. I do you, we talk about input, processing and output. And there's a fourth level input processing. And I like to think about it, taking it to a deeper level, bring not just processing what came in, but adding to it at the alchemy of being it. Yes. And this emerging knowledge that then there's an output. And I guess in those four different stages, if we stick with four, you've learned all about that and NLP and more and more like like what you talked about touch in the body. What? Yes, it's your body. I mean, a lot of people who can't learn need to be moving more, they get distracted by their bodies discomfort, for example. And mine was a negative self talking wasn't just the self talk interrupted my trying to remember my French words. It meant that I was interrupting the whole thing. Distracting myself. Right. Do that. I have two colleagues who've just gotten standing desks. And you know, you made me think about that. It's yeah, your body gets in the way. I mean, it's interesting. I mean, one of them was in her 60s. And she said, I'm standing. I hope you can tell on the zoom call because I just but I had lawyers in the law firm that I worked with in Honolulu in the 1970s. He had a standing desk built by by the firm so he could stand. So I don't know in the early days of that being something that work. Well, yeah, I've worked with a lot of ADHD kids because I started working with kids because the people I was working with two psychiatrists and a social worker didn't want to work with kids. And so after I learned how to learn, I said, well, I'll take the kids because the parents would come in, if I'm not telling you too much, they'd come in and they'd have a characterization of this child. This was way early in the ADD period of time. But they'd say desk doesn't try. She's too social, very few women. I was one of the few girls that could have been in that category. So if he just try harder, he just doesn't care. Well, I found out that the kids would say out of care, because that was better than saying, I'm not smart and I'm failing. And so I taught them what I had learned. And I called it Brownbrain 101. Okay, so hack the brain, if you will. Yeah, how to use their design memory, their image making process in their minds, how they could coach themselves before coaching was cool. In fact, they didn't even want to come to me because I was a psychotherapist. And I said, Oh, no, I'm not a psychotherapist. I'm an academic coach. And that was just made up so I could reframe it and get in sync with these kids that were suffering. And I talked to one of the guys just today that was the president, he was the head of Pace Academy in Atlanta. And he started my work off by sending me more kids when he heard me speak about it.  And you said, Yes, and I don't, then I talked about what do you call the people who work with kids tutors.  And that was important. It was huge because I had to get just like we get in like, in sync with the horses, I had to get to sync with those kids so they trust me. Oh, right. And all the same process. And yet it wasn't stigmatizing academic coaching. So you're coaching somebody who's already smart. You're not a tutor teaching them something they don't know exactly.  Yes. You know, as an adult, we are more people I I talk one when I meet somebody and I think you should go to counseling.  But today, if you say, well, you know, there are a lot of coaches, executive coaches, and this idea of executive coaching is is much more palatable. And you seems like maybe 20, even more years ago, you were already over 30, you refrained this to academic coaching. So we've got academic coaching on the table and the horse course, and a little bit about NLP. And then in psych, I'm not sure we've plumbed the depths of what house psychotherapy unlocks creativity and innovation in us. I mean, it's, I know it seems self evident. And yet, well, it's, it's, it's another, it's another way of them getting to know themselves. As long as this therapist, the psychotherapist isn't interpreting what they say. So coaches are trained to ask questions to help people discover themselves, which was very different than the way I was taught psychotherapy. Okay. And you know, and, and so how were you taught? How was that different back in the day when I was learning my masters and getting started, I worked at it for five and a half years. The model was you just listen and you go, I'm exaggerating for the sake of effect. But this one guy was teaching about psychotherapy and he says, you never want to direct them in any way, you know, don't lead them. And he said, you could have two different things that they're, they're wanting to think about, you have this and this, and which one will it be? He led them with his non verbals. And I was like, yeah, that's an NLP thing I learned is that you can do that, but you don't want to do that in psychotherapy. They will need to listen and people discover for themselves. And it's much more complicated than that now. I am not putting it down. I'm just saying the way I learned it really didn't seem to fit with the other things I was learning concurrently, which was the NLP. That's really interesting. So what I'm hearing a theme here, just as a student of yours, lock my own creativity is, is I want to, it seems like we keep smashing on this show the idea that only a few people are creative. And, and many people thinking I'm not creative. And the theme from you is to learn to know yourself.  And it says, I should know it because I have it pasted on my mirror. Don't ask how to make the world a better place. Out of Split makes you come a lot because what the world leads is people who have come alive. And a fall. Yes.  You're right. We'll follow. If we don't, yeah, if we don't care. So in, in the, can you tell us a little bit about your corporate side? And I was, I was called that in, when I was in school, I was a business major. We, it was called learning and development. Right. It still is. It's still in development, professional development depends on the culture of the company. I was invited to join a company. Oddly enough, because I'd worked with one of the kids of the HR person. And she wanted me to come in and, you know, tell me what we could do for learning and development to teach the stuff that I'd talked to her about. And so there were interviews and there were three of us that were applying and they hacked me. And I never ever wanted to go to another corporation. However, Tokyo Electron is the name of the company and it's wonderful. I love the people and their, the leaders were interested in learning. Yeah. In fact, I had a whole gang of them come to the horse course at one stage. Oh, yeah. They had fun too. So you, they hadn't had a professional and learning development department before you guys. That was a young company. It was a lot, a young part of the company. Yeah. Companies out of Japan, but the sales and service is here. And they had only been in business a few years. When they hired me. I don't remember how many exactly, but it was, it was new to manage all of their customers like Intel is one of their customers. So when, so if someone watching the show is in a corporation that is blessed the house, an L and D department or a professional development department, that's another way to step into this space to get to know that know thyself. That's very secret. Even if they don't have a department, I mean, I just got a contract confirmed with some other coaches to work with an energy company that does not have their own. So they come to us and say, we'd like to have this, this, this and this, can you do it?  And we will deliver it as I work with a lot of smart people. Well, and so for the viewers who are corporate leaders, business owners, this isn't new, we all know about it, but it's good to remind ourselves to, to the, this is, you know, I'm a financial person too. And yeah, what I like to, the way I see it, whether they do or not is that this is not an expense item on your, on your financial statement, but it's, it's, it's an asset. Yes. Money that is invested in the human sources of creativity. And then we're not resource because that's consumable and it can disappear. But we thought that in my work, we talk about human beings as sources, like sources of light, like the sun, not a, not a resource that can go away, but that this is an investment in themselves and their company. And it should be considered an asset. It should be, it should grow their investment in intellectual capital in their company. Absolutely. And then, you know, we could go on and on and on and I'm going to have to leave it there. We have more to cover, but for today's show, I only think I would say, Phyllis, is that what we do in learning, yeah, helps all the rest of the stuff work better. How do we get work done through people? Yeah, if you can't communicate and understand how people think in a lot of ways, you're not collaborating or communicating well. So what is going on? So anyway, I just love my work. Well, thank you. And I want to let the audience know you have been watching the creative life from the American Creativity Association's Austin Global Chapter on Think Tech, Hawaii. Today, we have been talking with our guest, Diane D., master coach, master certified coach. And we've learned how to knock our brain using the learner's edge. You can find more out about that going to thelearnersedge.com and Mahalo, Diane, for joining us. And Mahalo. Thank you very much. You're welcome. And Mahalo to our our viewers for being here. I'm Phyllis Blyse and we will be back in two weeks for another edition of the creative life.


Today, we're gonna see just how far $50 versus $500 will get you in Madden.  How true is it? Now keep in mind, this is not a pack-and-play.  I'm gonna spend 50, see what players I wanna keep, see what players I wanna sell, and use those coins to build the best squad I can. Then I'm gonna play a game and see how well the team does. After that, we're whipping out my mommy's sweet, sweet credit card, and we're maxing that puppy out. $500 to do the exact same thing. Now $50 will get you $5,850 Madden cash. I know that says 45, but that's because I have EA Play. You get a slight discount, but I assume most of us don't have EA Play, so I'm gonna pretend this is 50. So the best thing you can get for $50 is the six times all Madden bundles. Six all Madden packs and four 82 overall all Madden players. Now funny enough, EA's not actually letting me buy points right now, and that's a sign from the gods to stop giving EA money, so I have a different idea. We're just gonna build this bundle by buying all these packs, but with coins instead. So it's a win-win. We get the same bundle, but we don't have to give EA money. Hey, those are all Madden player right there! Lawrence Taylor, he's gotta be worth something. Jordan Brooks, hey, I'll take it. Don't worry about the coins. I can't use any coins that are already on this account, I can only use coins that I get from selling the players. But here's our second all Madden pack. Mike All-Stott, I like Mike All-Stott a lot. Tevin Coleman, okay? Just one elite in this one. Come on, baby. Come on! Oh Lord, dude, if I get one of the 89s, oh my God, this team will be cracked. George Pickens, menace. I'm getting Black Air Force Energy. Let's get it. Zac Pascal got an elite, Quentin Bohana, take it for the coins. Another all Madden player, Joe Montana. Jordan Poyer, 84, that's huge. Our final all Madden pack, I'm gonna be totally honest. As much as I'd love amazing pack luck, I almost like this standard pack luck better, because this is actually gonna show, even if you don't get insane odds, just how good of a team you can build, because I didn't pull any 89s right there. And I do get a lead here, Brian Burns, 82 will take it. And our top are of four all Madden players. I think these can technically be the 89s. Yeah, they're 82 plus, so Ronnie Law, okay. Number three is Lawrence Taylor. Our fourth and final all Madden player, let's see who we got, Sam Mills.  The 2022 season kicks off this week.  And DraftKings Sportsbook, America's top rated sportsbook app, is putting new customers in the center of the action, with an opportunity to instantly turn just $5 into $200 in free bets. That's right, DraftKings is giving all new customers $200 in free bets, when they place any pre-game $5 bet on the college football team of their choosing. Plus, with same game parlays, you can combine multiple bets on the same game to give yourself a shot at even bigger winnings. Again, new customers bet $5 on any pre-game college football wager, and instantly receive $200 in free bets. It's that simple. DraftKings has so many ways to make watching sports that much more fun. So download the DraftKings Sportsbook app now. New customers use promo code MMG and receive $200 in free bets instantly when placing a $5 wager. That's promo code MMG, only at DraftKings Sportsbook. And that's why I'm excited to partner with DraftKings Sportsbook today. All right, so that's our $50 bundle complete. I do wanna do a set. I don't wanna include any of those gold players we've pulled on our team other than George Pickens. So I'm gonna trade them out for an elite. Hopefully we can get somebody that's worth a lot. So we can redeem the free Joe Burrow and two of the gold players that we pulled for an 80-81 overall elite player. We should have just enough golds for one more. An 81 would be amazing. Gonna be certainly worth more. Let's see what we got. Hey, Jermaine Pratt actually, actually a nasty user I'm pretty sure. We may just use him on the team. Yup, and we have just enough golds for one more 80-81 elite. Let me see, let me see, let me see. Rashad Fenton, you know what? Honestly, Rashad Fenton is trash. I'm selling him. We'll use the coins to buy a player we really want. Now if we were to quick sell all the remaining gold players on this team, we'd quick sell 21 of them for 1,189 trading. I'm actually gonna use that and head to the training store see if there's anything I can pick up that's worth it.  We profited five training. He's actually a really good quarterback. Accuracies aren't there, but 80 speed, 82 throw power, might just use this trade lands. You know what, the final three, I'm gonna go 78 plus. This isn't the most efficient way to use the training we just got, but I'm going for the Hail Mary to get Julian Aquara on the first one. I'm gonna need an 82 overall or better player here for this to have been a good decision. This is a little gamble. A little Calvin Ridley action right here, but I respect it. Cadarius Tony, I'll happily use the players I get though.  Low key for my O-line, I think 80 overall is gonna be too expensive. I'm gonna go full budget 78 overall O-line. I still think they're gonna play great. I want a stud quarterback and it's 33K for Russell Wilson. Broncos country, let's- Ah! Everything is sold. We've got 153,000 coins plus the 53,000 we already spent. We made out with about 206,000 coins on that bundle. We've got our quarterback and our offensive line and 153,000 coins to spend. I know exactly who I want. Najee Harris, 21,100 coins.  I'm excited. Ironically, the cheapest tight end is actually all Madden Tony G. He's really good. Also, Darren Waller is incredible. I'm willing to spend 36,000 coins for him. I'm gonna grab DJ Moore for 9,500. Also Jalen Waddle, 84 speed for less than 10K is a great steal. Next to me, Fast Corners. Taryn Johnson, Jamel Dean, and Lageria Snead. Safeties, I'm gonna take Jabril Peppers and Buddha Baker. Small safeties, but I think they'll get the job done. Outside linebackers, I'm gonna go Golds. I think I can get away with it. Go Daryl Taylor and Leonard Floyd. D-Tackles are actually really, really strong this year. So I'm gonna spend 16K on Javon Hargrave. I think Jerry Hughes for 9K is a good way to round out this team. And with 700 coins to spare, we have just finished our entire lineup from $50. All right boys, here's the $50 squad. 78 overall, all gold offensive line. Stud Daryn Waller, Stud Russell Wilson, Stud Najee Harris. My wide receivers are meh, but I still think they can get the job done. DJ Moore, Garrett Wilson, Canarias Tony. I seriously think this team's gonna be kind of sick. Oh, his team's looking really good. Big round of applause for Electronic Arts. All right, here at Waller, right in the middle. Oh, DJ Moore! Dude, what was he doing? Did he pull his safety?  Completely lost. What a great start to this game. Oh, right there, Moore, got him. Ooh, yep, you saw it right there. Oh, he's not in, damn. Oh, fake Blitz, ah! Get there, get there, get there. No, somebody get him. Engram's kind of fast. Blitz, Buddha Baker wide open. Oh, nice. Damn, he's breaking. He's breaking everything. A goal line stand. He's got a settle for three. Great work. I wanna get Najee cooking. I wanna get Daryn Waller cooking. We gotta play through our studs, right? Wide open, great. Throw Russell Wilson under pressure. There he is. DJ Moore, great pickup. He's got run and gun activated. We're not even in the second half. That counts as throw on the run.   I completely dodged this Blitz. I'm throwing B, sketchy, mad. You got greedy, I got so greedy, bro. I got so greedy.  But I smell a wide open. Daryn Waller breaks a tackle. Is Waller open outside release? I think, oh, no, no, no, no, that's sketchy. Just get up, get up, get up.  He's got his X factor lit up. Daryn Waller's got double me going. Oh, great blocks up front.  Very much man coverage. Oh, my God. Beauty, the DJ Moore. Great post route. But gosh, that post route's gonna keep killing him if he's got that safety so damn high. That safety's like 30 yards back, dude. Oh, fuck, that's kind of there.  Let's go. Nice defense, nice defense. A, but a 13 point lead. I'm not unhappy. Kick returns are good. Kick returns are very good. I had Y, oh my God, I had him for a laser beam, but I also have X. Maybe I don't, maybe I do. Holy Blitz, bro.  Bro, go watch that back. Go watch that back. Nobody touched it.  How unlucky all of that was. That sucked. Guy pulled out the Glitch Blitz playbook and I got screamer twice. All right, well, gotta make a big play here with two minutes, 25 seconds left. I can't do anything now. Oh my God. 312 yards, two touchdowns for nothing. Great throw. Got rocked. We gotta pick this up. It's fourth and four. This absolute bum, Kyle Phillips. Great blocks. Wow. Great run, Najee Harris. There it is. Oh, nice play though. That was a pretty sick play there at the end. What a bummer of a game to lose, bro. Kick return, pick six, two field goals. You know what, regardless, I'm very proud of our 79 overall team. I think we played really well. Nothing you can do about a kick return though, so sometimes you gotta lose games. All right, boys. We're on a brand new 100 dollar team. So 135 bucks or really 150 if you don't have EA play gets you 18,500 cash. So I can do three of those and then another 50. Right now let's spend this first 18,500 to see how good that can get us and we'll go from there.  Abe, Iron Murphy. They're on pain. Abe, we're gonna get a triple. We're gonna get a quadruple elite.  Five elites. Oh my God, and it's Kyle Pitts, bro. This is the luck we needed on the $50 bundle, bro. Oh my God, that's insane. Bruce Matthews, Kyle Pitts, Saffolder, Ron Payne, Byron Murphy. That is nuts. Let's go. Jacobi Myers, dude. And another one within St. Pac, like Casey Hayward, like All-Star. Randy Moss, Matthew Stafford.  I got at best an 84 last time. Aaron Jones as well. Lamar Jackson, Lawrence Taylor. Is this bundle, 12 pro elite packs?  An eight to 80 plus elite platinum players, so I can quick sell those for coins. Andre James, Charles Leno. Kenny Moore, Bruce Smith, and Josh Jacobs. Lavante, David, 84. Beast, Corey Linsley, JJ Watt. Squad. Jay Jettos, Jay Jettos. Let's go. I can't wait, dude. I'm definitely keeping him on the squad. Kyler? Kyler could be our quarterback, although I think I'm gonna be able to afford a significantly better quarterback. This is a guaranteed 86 plus elite. This could be something nuts. It's a pro platinum 83. What? Wait, does this include, is this the whole, does this also have all of the platinum players in it? So the toppers all like technically one pack. These are my eight platinum players, plus my 86, which is a Nick Chubb. I was hoping to be over 86. But yo, 85 trade mine digs, that's gonna quick sell for a crazy good amount. And Riley Dixon is okay. So quick sell on all these guys gives me 185,000 coins, and we got Nick Chubb. Dude, I actually really like this, this pro league bundle. I'm gonna do it again. Quandre Diggs, Michael Walker. Taylor Moten, Tremaine Edmonds. Mad Max Crosby, Jason Kelsey, double 84s. Khalil Mack, 85, and Brian Burns. That's a dope pack right there. Let's get it. Ooh, okay, this is our topper. This is our topper right here. We need high overalls, 83 DK Metcalf. Just keep going high overalls, baby. Gilmore 83, amazing. Keep it up. 80's, so that's my 86 plus. It's a kicker. So expensive.  Amoner St. Brown, DJ Jones, Lane Johnson. Denil Hunter, Dalvin Cook. That's huge. So coins straight into the account. I've spent exactly $300 as of right now. This will take us to 450. And I think I'm sticking with this pro league bundle. This thing has been absolute fire. Huge elite pack, Tyus Baus Lageris, Sneen Michael Pierce, and Cordero Patterson. Kendrick Bourne, Chris Lindstrom, amazing right guard. Oh my God, Corey Lindsley once again, Charverius Ward, Hunter Renfrow. Johnny Hecker, Mack Jones, Big Mac Jones. Bobby McCain, Desmond King, Jaylin Waddle. Wyatt Teller, 86, Jacoby Myers, 80. Darren Waller, amazing. David Bakhtiari. Foyasad Alouicon, Leighton Vandoresh, Ryan Jensen. CJ Gardner, Johnson. Errolanger, we haven't seen our topper yet. It's our topper. It's Cam Jordan, 86. Damn, getting only 86 is no 86 plus. AC Hayward, Cam Jordan. So I have to sell Cam Jordan. I have enough for one more big bundle.   And Shaq Barrett, CD Lamb, and Amani Hook.  Obviously, we're gonna make a good team just off of what we pulled, but selling all the bench players and then truly choosing what we want, this team is gonna be insane. My Kilton Bohana, Owosu Karamola, and Tony G, four elites in them. And our topper, all platinum players. There's 81 miles Jack, Brazil Douglas. Derwin James, that's a nasty bull, 85. Vita Veya, 84. Christian Wilkins, love him. And Trey Smith, ending it off with a 95 right guard. That's amazing. We can guarantee an 86 headliners hero for 950 cash, that's actually a really good deal.  I'm not using Carson Wentz. And with our final 250, we're gonna get one headliners pack if we just get crazy lucky. Hey, you know what? Milton Williams getting an elite out of just that one is awesome. Yeah, 14K, I'll take 14,000 coins. Do we make it Jalen Hurts season?  He comes with escape artist and quick draw. 525, who's gonna stop me? It's the $500 team. Joe Mixon is incredible. I think that might be the move. Adrian Phillips is 139K, but he looks awesome. Let's go Adrian Phillips. Latimore is awesome for 33K, absolutely. And AJ Terrell gotta get him, bro, I love him. With most of our more expensive players sold, I think I just want an amazing middle linebacker and I'm actually gonna be happy with this team. I think I wanna use Devondre Campbell. He's 106K too, which isn't too bad. 75K for Quitty Pay, let's send it. Shocking revelation. Spending a lot of money on Madden gives you an insane team. I've got about a million coins in the backfield here. Jalen Hurts, Joe Mixon, Mike Allstop. I got 15K coins left over and I honestly still have players that I could sell but I don't even know what I'd wanna upgrade super badly. I love this team and I'm ready to play a game so I don't think we gotta go crazy overkill. $50 for the 79 overall was like a really, a team that could compete. He's got Wentz, Derrick Brownschmarche, solid squad as well. Yeah, it didn't look like that team though. Let's go left side, stretch, great blocking. Oh my God, wait a minute, hard cut, 16 yards, Joe Mixon. Look at B. What a throw to CD Lamb, great catch in a very contested window. Is Kyle Pitts easy, keep it simple, keep it simple. Damn, he got around those blocks so easy. Oh, can I even throw that? CD Lamb, wait a minute, that's a touchdown. Ooh, nice play, Joe Mixon, he's gonna get it. Eight to zero, nice start. Let's go, wait, Devandre, no way. Yup, yup, Kenny Moore, great tackle. Wow, deep bomb up to Mike Evans. Way to get that out of there, boys. Oh my God, dude, he's, oh, I wish he was in bounds. That's a touchdown, he's torching it. The dig, the dig, oh, just kind of a poverty greedy, I'm not gonna lie, not the best animation but wait for him to clear, wait for him to clear. Oh my God, that is so money, 16 to zero. A few moments later. Perfect, perfect, oh, nice window. I thought Lattimore was gonna get that. Does he throw right side? Oh my God, that could not have been more open. I don't know what happened. Yup, Phillips, oh no. No, I literally knew exactly what play it was. That J.K. Dobbins is chilling, dude. Ooh, nice playmaker, but the two point conversions are the difference in this game. You know, two point conversions lost me the first game, they might win me the second game. Kyle Pitts has his X-Factor activated?  It's pretty easy decision then. Got him, laser beam fear, waller, great catch, let's go. There's no planches, man, I literally have no idea.  Guess I'm just going up to Jay Jetta, oh my God. Just, just set one straight at him. Let's get it, cut inside. Great cut, 12 point lead.  I should have bought a better corner. Well, no, I feel like Leadmore's really good. That's just going to happen. I was running press coverage, being aggressive. Ooh, man coverage, you're in trouble? Ugh, no way. All right, Joe makes a good tackle, bro.    How did you catch that? Oh my God, oh, it's a fake. Get there, get there, get there. Bro, this guy just went deep in the playbook. That was kind of sick. Well, he hits that one, so now it's 25-24. I don't think I'll make the same mistake as last game. I think I'm going to put this one away. Beautiful throw, Jay Jetta's wide open. Same exact thing, Justin Jefferson. I'm going to need mommy's credit card to clutch me up here. Great throw, Justin Jefferson getting great yards. And there's Tony G. I believe he just iced the game up. I had three timeouts, no ice.  Guess he doesn't matter if it's my mommy's credit card, my daddy's credit card, or no credit card.  All right, boys, that's the $50 squad versus a $500 squad. I hope you guys enjoyed an absolute blast to make. And I'll see you guys in the next video. Peace.


I am delighted to speak to one of the representatives of the host country, Switzerland. It is Mr Philipp Metzger, who is the Director-General of OFCOM, the Office of Communication. Hello. Good morning. Well, it's lovely to see you here. Obviously OFCOM is entirely the most appropriate body to be here. Tell me a bit about your involvement with regards to multilateral international organisations and processes such as WESIS. Well, as the Federal Office of Communications, we are part of the Ministry of Infrastructure by and large, including communications and ICT. And of course we are in charge of making sure that Switzerland can make itself heard in the different fora and indeed international organisations that are dealing with ICTs and with the promotion of the Information Society, including the Internet Governance. Now, Switzerland as a relatively small country in the centre of Europe, does this mean that in a way you are more agile, you are more able to take advantage of new technologies as opposed to larger countries with huge populations? Well, I think if we look at the different indicators how ICTs are being used for the benefit of society and business, I think we are doing well. But of course on the other hand, especially when you talk about network economies, there's always an aspect of economies of scale. And so I think we have to balance that. On the one hand, yes, we are agile because we're relatively small. We have a close contact to stakeholders. We can adopt or shift policies relatively efficiently on a dialogue-based approach. But on the other hand, of course, we are a market that's relatively small. And so I think we have to, we have to, that challenge to pick up. But overall, I think we're pretty satisfied the way we are doing with regard to ICT development and the status of the Information Society. And as an advanced, wealthy country, obviously you have advantage over less developed countries. But are you satisfied with the progress that's been made? Or do you think that Switzerland can do more, can be even more of a leader in the future? I think we're trying to be extremely committed to these processes, including of course the process we're here discussing here today with this and the RISIS Plus 10. You know that the first phase of RISIS took place in Geneva in 2003. And so we are, again, as a small country, also a small administration. And my colleagues and I are working extremely hard to make sure we can cover as many international activities as there are and not only cover them, but actually shape them and try to help find common solutions because the ecosystem within which we're operating has become incredibly complex over the last few years. Well, let's talk about the Geneva Internet Platform. Tell us more about that. Now, precisely picking up on the complexity of the ecosystem when it comes to the world of internet, I think our aim is, maybe I can put it into a very catchy phrase, our aim is to provide a silo breaker in a sense, because in a very complex ecosystem you have many different processes, you have many different stakeholders, you have many different institutions with their own governance. And I think crossing the lines of all those different components ultimately has to be a goal of all of us because we have to work together. It's not good enough anymore as the government just to put out ordinances and put out orders from the tall horse. You really have to engage with the stakeholders, including civil society. And I think what we're trying to do with the Geneva Internet Platform is provide a tool for all those parties, regardless whether they are from developed or developing countries. Of course we also want to make sure that developing countries can get the know-how they need, but we want to try to be really inclusive, promote and put a platform at the disposal of everybody to speak to each other, understand what's at stake, understand each other's policies, understand each other's processes. So it's really a neutral platform. It's not at all to spur or to advocate one position or the other, it's really to ensure a maximal transparency. I think transparency is a very important aspect in the entire discussion about information society and help hopefully all the actors who are already in Geneva, because we have many agencies, many companies, many NGOs that are in Geneva provide a platform for them, but also delegates who are business travelers who are dealing with information society and ICTs who are in town to profit from that platform. Philipp Mezca, thank you very much and enjoy the rest of the conference. Thanks.