So, hey everyone, I'm O'Conn. I work on identity solutions for VMware Tanzu. I have worked on Kubernetes for over five years now and have been co-chair for SigAuth for over three years. And I'm Margo Crawford. I'm an engineer for VMware Tanzu as well, working on Piniped, which simplifies the Kubernetes Auth experience. For working on Piniped, I've learned a lot more about the features and shortcomings of built-in Kubernetes Auth, so I'm excited to share some of those learnings. Cool. So in this talk, we're going to talk about some of the capabilities of Kubernetes Auth today and some of the limitations. Then we'll look at some workarounds that we did to work around some of the limitations. And then at the end, we're going to try to look forward and see what we could do in the future to make things a little better. So let's say you want to configure Auth in your Kubernetes environment, right? Seems like a pretty simple straightforward ask. So let's look at the cloud providers, right? Because this is generally the entry point for most Kubernetes users. Because the reality is, managing your own Kubernetes infrastructure is hard. Kubernetes does not handle that part of the problem. All right? So if you're using GCP, you're probably used to using the G Cloud CLI. If you're using Azure, you're used to using their CLI. And if you're using EKS, you're used to their CLI, right? So each of these platforms has their own integrated IAM solution, right? And this is totally fine if you're all in on a single platform, right? But what if you're not, right? What if you want to use a different identity provider, right? So traditional enterprises tend to have corporate active directory with their user identity, right? And it's likely that they want to continue to use that identity in their Kubernetes clusters, right? You tend to have a pretty high investment in your identity infrastructure. And it's pretty unreasonable to ask people to change that, right? And enterprises want the flexibility to use any cloud provider, right? After all, Kubernetes is meant to offer workload flexibility and mobility across the cloud platforms, right? But having a unified picture of your identity across the cloud providers is an important piece of that mobility. So if you're trying to figure out how to authenticate with something other than built-in cloud provider off, you might find that Kubernetes OIDC authentication is a nice option. OpenID Connect or OIDC is a pretty common protocol for authenticating with an external identity provider. It's an exception of OAuth 2.0. You can configure your Kubernetes clusters so that when you run kubectl commands, you can just include your ID token and the claims in the token will map to a Kubernetes username and groups. Unfortunately, this doesn't work in a lot of cases for a few reasons. A big one is that it requires configuring the API server. If you're self-hosting, this is something you can do by setting a few flags. But a lot of Kubernetes users don't have that option available because they're using cloud provider distribution and they aren't allowed to set API server flags at all. In contrast, Admission Webhook can be configured dynamically. So something like OPA Gatekeeper can be deployed by any cluster administrator at runtime in a cluster agnostic way that doesn't differ between cloud providers and self-hosted. So configuring the API server makes this option impossible on GKE and AKS. But EKS actually does have the option of configuring OIDC using their own proprietary API. It's not a bad option if you're using EKS clusters and you have an OIDC at any provider. But if you're configuring the API server, even if you can do that, you still won't have the option to update your configuration at runtime. For example, if you want to rotate OIDC client credentials without taking down the cluster. And of course, if you're using an identity provider that doesn't support OIDC, like Active Directory or LDAP, you're out of luck. Not to mention, this is just a building block. Kubernetes doesn't help your users get Jot tokens, it just validates them. Kubernetes has a bunch of extension points for authentication. So let's go through a few more. Starting with those that require API server configuration, we've got OIDC like we talked about on the previous slide. It works great if you have an OIDC compliant identity provider to work with. Another option is to create an authentication webhook. When a user provides a token to the API server, the webhook will call out to an external service to authenticate it. This is very flexible, but it requires you to write code and be responsible for that webhook. There are a couple other options that are typically enabled by default with common tools used to deploy Kubernetes, like QBADM and most cloud providers. One is certificates. You can generate client search for users based on the cluster CA. One problem with this approach is that certificates aren't revocable, but we'll talk more about that later. Service account tokens are another option, but as the name implies, they aren't meant to work with humans, they're for service accounts. So let's talk about what we would expect end users to need, right? So if we look at the bottom of the slide, we can see a kubectl command, and I would venture to say that many Kubernetes users expect something like this if they're trying to configure Active Directory in their environment, right? It's a custom resource-based API, and then you can use standard kubectl commands to try to understand the API structure and what configuration options are available to them, right? So at the highest level, right, they want to bring their own identity to Kubernetes, right? And it doesn't matter where that identity comes from, it might be Active Directory, it might be GitHub, right? They want to be able to use any identity provider that they have available to them, and they want to be able to do this even if they didn't stand up the infrastructure themselves, right, in the cloud provider environments, as a for example, right? They want to have a consistent identity across all environments. So if you're very familiar with Active Directory, you might be very used to using, like, user principal name as the username attribute in your Kubernetes RBAC roles, or perhaps you're an ultra-paranoid, and you want to use object good, but either way, you're used to a particular way of asserting identity across your infrastructure, and you want to keep doing that, right? So as we saw in the bottom of the slide, right, you want to make this stuff easy for people, right? They should be able to understand it in the same way they understand everything else in Kubernetes, right? So a custom resource-based API is really ideal for that, and you know, you want it to be a higher-order API, right, we're not talking about webhooks, we're not talking about tokens, right? We're talking about identity providers, because that's what people understand, right? And you want to keep all this stuff as safe as possible, right? So you want to limit the negative effects of an individual cluster compromise, right? So what that means from the perspective of an end user is there's no credentials that are being sent to clusters that can then be replayed across clusters, as a, for example, right? So if we step back and then instead look at what do the implementers need, right? So Margot and I are the pinniped authors, along with some others at VMware. So what do we need to solve these problems for folks, right? And it really comes down to a pretty simple requirement, right? We need some way at runtime to assert identity on a Kubernetes cluster, regardless of how the infrastructure was brought up, right? So the extension point that we need to integrate with has to be something that's always enabled, doesn't have any configuration, it behaves exactly the same way on every Kubernetes distribution, and probably most importantly, it has to be safe for this purpose, right? It has to be designed and built for this purpose. So that takes us to work around number one that we implemented. So a little background, X509 client certificate off is enabled on most Kubernetes distributions with the exception of EKS. There's an API for signing those client certificates called the certificate signing request. It's got a few problems though. A big one is that up until Kubernetes 122, when Mo added the expiration seconds configuration option, there was no way to configure the length of certificates, and the default lifetime was one year, and the certs aren't revocable. Usually when you can't revoc a cert, you'd want to keep the lifetime as short as possible so that if users shouldn't have access anymore, their client will expire quickly, and when they ask for another one, they'll be denied. The proposed workaround for when you want to revoc a cert is to rotate the whole CA, which is not ideal and breaks a lot of things. You can always go around the certificate signing request API, but it requires saving the cluster signing key pair somewhere and issuing cert space off of it. What we did is we steal your keys from inside your cluster and use them to mint shortlist certificates whenever we want. So this only works if you have access to the Kubernetes control plane, which often isn't the case on cloud-hosted Kubernetes distributions. But if we do have that access, we can look at the Kube controller manager pods, which are part of the control plane in charge of the certificate signing request controller along with some other controllers, and we can see which arguments the daemon was called with. This tells us the path to the signing key so we can grab it from the volume mounted to the Kube controller manager. Let's walk through how this works using Piniped. When you deploy your cluster, it's created with at least one Kube controller manager pod. That pod has the volumes mounted, including one that includes the cluster signing key pair. In this case, the one called Kate's certs highlighted in blue. The user can deploy Piniped or anything else using the same trick. The Piniped pod will read the metadata of the Kube controller manager to find the path to the cluster signing key. Then Piniped launches a privileged pod called the Kube cert agent and copies over the Kube controller manager's volumes. It also passes the path to the key pair as environment variables. Piniped can then ask the Kube cert agent for the key pair, which the Kube cert agent reads from its volumes and stored in memory. So when a user asks Piniped for a certificate, we can do our own authentication checks, then use the key pair to mint certificates of any duration we want. So as Margot mentioned, the Kube cert agent-based approach doesn't work in the cloud provider environments. Those are not self-hosted environments. The Kubernetes control plane isn't available through the Kubernetes API. We need a different way to handle those environments. Those are quite critical to us. So I've tried to make this like a happy rant instead of an angry rant. We'll see how this goes. So I'm pretty sure many folks are familiar with impersonation through Kube CTL. So you can see the command on the bottom of the screen. Someone's trying to get pods, but they want to run this command as a different identity. And then the curl command right under that sort of describes what is actually happening. So you're authenticating as some identity, and then you're asking the API server, hey, I want to act as some other identity. Do some authorization checks and let me act as that other identity instead. All right, so this was originally built in OpenShift. And when it was upstreamed, it actually lost some functionality. So OpenShift has a very strong concept of groups. So back in those days, when you impersonated a user identity, it would automatically impersonate all the groups that a user belonged to. That got lost when we upstreamed that years ago. So it's built with a pretty simple server-side implementation where the incoming request is processed. When the client sends these headers, the API server is effectively saying, all right, you're authenticated as Margo, but you're trying to impersonate Moe. I'm going to do some extra authorization checks to assert that Margo is allowed to do this action. And if so, I'm going to basically overwrite the user information on the request. And the rest of the request will run as if Moe had run the command himself. And most critically and importantly for us, impersonation has no configuration options, and it's always enabled in every environment. So let's walk through some use cases for impersonation. If you guys are familiar with modern IT principles, you no longer run as a privileged user unlike your Windows machine. You tend to run as a limited user.  So you can do the same kind of flow with Kubernetes. You can be a cluster admin style user that purposely limits their own access in the normal day-to-day operations, but then they have the capability to impersonate a root-level identity to grant themselves extra permissions. So that's one common use case for impersonation. Another one is the I want to validate access use case.  So how can we abuse this? We'll see. So let's walk through this example. Let's pretend you have like a magic box and the box can do something. And there's a user trying to get pods, and you happen to know that impersonation is a thing and you are ready to abuse it to the maximum of your capabilities. So what does the magic have to be for you to figure out what you need to do with impersonation? Well, generally speaking, that has to effectively be authentication. You have to know who is trying to make a request before you can impersonate them. So once you have that, once you've authenticated the user, now you know what headers to set. But you yourself need some identity to do the impersonation. And since you didn't know who was going to show up, you basically have to be able to impersonate any identity. So what you're talking about is some root-level account that can impersonate all other users in the system, whether they exist or not. Start making you nervous. So now we have sort of the building blocks of like an impersonation proxy. Now if we step back, what is the user seeing in all this? Well, everything behind the magic box is completely opaque to them. They have no idea that any of this exists. From their perspective, they're talking to the Kubernetes API. Just the difference is we've lied to them. We've told them to the Kubernetes API servers over here. Just ignore the real one over there. So like if we walk through a full example, you have a user, they're trying to get pods, they go to your reverse proxy, which authenticates them using whatever means they want to authenticate. And then it turns around and impersonates them on the backend to the real API server using its own root credentials while setting the impersonation headers. So in text, you're going to lie to the user and tell them the URL and CA bundle of the API server is the impersonation proxy. They're going to send all of their traffic to the impersonation proxy instead of the API server. And the proxy will authenticate them however it wants. And then it's going to reverse proxy that back to the API server with the appropriate impersonation headers and authorization header set. So what can go wrong, or sorry, what is wrong with this approach? Well, there's a lot of things. First of all, you're sending your traffic to the wrong place. So every time you type in like kubectl get secrets, all of the plain text of those secrets is flowing through this proxy. So you have basically made another root level component in your infrastructure. And this proxy now has to fully scale with all of the traffic that you pushed through it. So previously you had one API server and now you effectively have two because it has to linearly scale with all the traffic that's being flowing through it. Also, there's no way to prevent the user from trying to access the real API server. The Kubernetes default of service is available in every pod. So if they happen to try to authenticate to the real API server, it won't work because only your magic proxy understands whatever credentials it issued. The API server will very happily reply with unauthorized, which is a misnomer but it's an incredibly infuriating error message as a user. As an IT security person, you should probably freak out when someone tells you that there is an identity on the system that is allowed to impersonate all other identities because that's awful. Like this is asking for something to go wrong. And as I mentioned, the impersonation implementation was never designed for this use case. It was designed for the things I showed earlier. So imagine you're someone who's using Active Directory and you're in like a hundred groups or maybe more realistically, even a thousand groups when you turn around and do that reverse proxy to the API server in the inline request, the API server is going to linearly validate that that super user service account is allowed to impersonate individually each one of those groups. Now those are very fast checks, but it's not something that you want to sit there and do in the middle of a request. It's just not a sane approach. And probably most importantly is impersonation is the first class functionality of the Kubernetes API. It's built into Kube CTL and you've created a big problem for your users right now. How are they going to use impersonation if you're abusing it on the back end, right? Impersonation doesn't nest. You have to come up with some other strategy to allow users to keep using that functionality while you're trying to use it on the back end. So let's talk about how we implemented some of this. So the business logic of our impersonation proxy uses or abuses for a better term the API server aggregation code from the Kubernetes code. If you ignore comments and imports and that kind of stuff, it actually is very tight. It comes down to under 500 lines of incredibly dense and cryptic code, but it's not that much code. One of the things that we did because we didn't want to lose the ability to handle impersonation on the front end is we performed the same authorization checks that the API server does when you try to impersonate something, but we wanted to make sure that in the Kubernetes audit log you could always see all three actors that perform this request, right? So obviously our service account is the one making the request. The identity that you impersonated is the one that the request will be run as and then in the user info of the request and on particular key, we insert the information of the user that made the request to us. So if you ever look at the Kubernetes audit log, all three actors are maintained within that log. All right, Margot added the ability to do a UID impersonation in 122, but that's very, very recent in Bleeding Edge. And one of the core things that we wanted to maintain is one, we didn't want you to lose any functionality if you're using our proxy, but also we wanted to make sure that no information is ever lost through this layer. So service accounts happen to always have UIDs in their user info. So if you try to impersonate a service account, that information would get lost. So in this particular case, we would pass through the tokens for the service account. Maybe one day we won't have to do that when everyone is on 122 and greater. So I'm sure everyone's familiar with CubeCTL exec and Port Forward and all of those things. Those are incredibly important to the Kubernetes developer experience and we wanted to make sure all of that stuff was also maintained. So we fully support speedy and WebSockets and all of that stuff through our proxy. This is one of the few places that where we diverse from Kubernetes. We don't use the Kubernetes code to do this stuff because it happens to be the code that had the most critical CVE in the history of the Kubernetes project. So we just decided that it was better to heavily rely on the standard library instead of what Kubernetes does in this place. And of course, watches are super critical to the Kubernetes experience so we made sure those still work. So after all of that, does anyone think they can write a correct, safe, performant, and otherwise perfect impersonation proxy? But I'm going to say no. No, you cannot. And I have proof that you can't. So I went hunting, right? And there's this really cool project called Kima that builds a bunch of higher order functionality on top of Kubernetes like functions and serverless and all the cool stuff, microservice stuff. And for other reason, they use an impersonation proxy. And they forgot to validate some inputs. It didn't work out so well for them. If you don't know about Kima, I'm pretty sure you probably know about Mesosphere. And hopefully you updated it last month because they also forgot to sanitize some inputs. And the underlying proxy code they use from a company called Traffic, by the way, these guys are amazing. They had the most phenomenal security response I've seen from a company in a very long time. For them, it was a pretty trivial, low value CVE. And as they clearly state in their disclosure, that the expectation of such an issue is very unlikely because it requires that the removal of a header would lead to a privilege escalation. Well, it just so happens that if you remove impersonation headers, you get a privilege escalation. And if you don't know anything about those companies, I'm really willing to bet you know about Rancher. And they also got this wrong. So if we walk through the severity of this, we can kind of ignore the network bit, everything on Kubernetes is this network. It's not really significant. The complexity of these attacks is incredibly trivial. You're just setting some headers on the request. In terms of privilege, there's no actual privilege requirement. You just have to authenticate. So it's like the lowest possible privilege. And there's no user interaction. All right, you're just attacking the network proxy directly. So the only thing really left is the actual severity of these issues. And it just so happens in all of these cases, all the ones I described earlier, every single one of them led to a completely unprivileged user becoming full cluster admin on the environment. So if we think about this in the recent trends of ransomware, I can tell you that you have no confidentiality.  You will have no integrity because it's going to encrypt all your data. And you will have no availability because all your data is encrypted and also you're for us running Bitcoin miners or something. So the only thing that actually left is did you have a scope change? Well, I don't know. Maybe it got access to other cloud credentials and then your whole infra is destroyed or whatever. So maybe you did. So you're either talking about a high or a critical. Either way, your day is ruined. All right, so we were always very nervous about building this. So we had always designed this stuff with a bunch of security thoughts in mind. So we always set all the standard security headers that you want to set to make sure everything is safe. We always did every input validation we could think of to pedantic levels. If we thought for any reason that we weren't going to exactly impersonate your identity bit for bit, even if there was a slight case difference or something, we just failed the request. We were like, whatever. We'd rather not do anything than accidentally do something wrong. But after learning of all these issues in our ecosystem, we took some further steps to harden our implementation just in case that we had some mistake that was unknown to us today. So if you happen to use Azure Kubernetes Service, they're the main cloud provider that disables anonymous authentication. So if you run our proxy against their API servers, it will automatically detect this case and honor that configuration for you. We happen to have one API that's a pre-login API. So that one is passed through, but otherwise everything else is rejected as you would expect in those environments. We use a distinct service account to handle this impersonation stuff. So all it can do is impersonate. So if you manage to make us drop our headers, the request will run as a user with no permissions. So at least that's okay.  Probably the most critical thing we do is we no longer rely on the API server to perform authorization checks for us. We pre-authorize every request using the subject access review API just to make sure that you're at least authorized to do the thing. We fully rely on the API server to perform all the admission checks that we needed to do, but on read requests and stuff, if we don't think you can make the request, we're not going to reverse proxy at all. So looking forward, we're hoping that one day these workarounds that we built are going to become obsolete. The ball is already rolling for certificates. So Mo added expiration seconds to the certificate signing request API, which means that we won't need our cluster signing key stealing hack workaround since we can request any link short as 10 minutes. This only came out in 122 though, which is super recent. So it'll be a while before it has widespread adoption and even then it won't work on EKS. And of course, it isn't a full solution. Even with the short-lived certificate, you still need tools built around it for logging in with your identity provider and refreshing certificates when they expire. These are all things that Piniped does and that you would need to do if you were implementing your own solution with short-lived certificates. So over a year ago, I had proposed the ability to have dynamic authentication configuration in the Kubernetes API. So that kept was rejected under the belief that it proposed a cluster configuration API and not something that should be built into the Kubernetes API server or set in a different way. The configuration belonged to the cluster operator persona and not the cluster admin persona. Of course, I disagree with this because I wouldn't have written the KEP otherwise. But I feel like there's probably some middle ground where we can try to find the good parts of impersonation without all the bad. So no proxies, no privilege escalation, no fail open behavior. So you could imagine maybe some token-based API that gives you identities from the cluster or something that either you set the token or you don't, but you can't break out of the bounds of some sign assertion of identity, as a for example. So to summarize, built-in Kubernetes auth is super flexible, but it's hard to configure and it's mostly not possible to configure it at runtime. We built some cool workarounds together on the pain points we saw by acquiring the cluster signing key pair from the control plane so we could mint short-lived certificates with it and by writing an impersonation proxy. And we're still working towards making our workarounds unnecessary. We believe that auth shouldn't be considered part of your infrastructure config under the control of the cluster operator is to be standard Kubernetes configuration under the control of the cluster admin. Having it be infrastructure config makes it hard to have unified identity across Kubernetes distributions. Pinniped uses a series of workarounds, but we don't consider them to be the safest approach to solve these problems and we think changes need to be made to core Kubernetes so it's easier and safer to build. We trust the cluster admin with near-complete control over authorization with Kubernetes RBAC and Admission Webhooks at runtime so we should extend that same trust to authorization as well. Authentication. Yes, authentication. If you're interested in learning more about Pinniped, we have learned the workarounds we talked about today and a full logging experience that lets you integrate with OEDC, LDAP, and Active Directory Identity Providers. You can read our source code to see how we did it on GitHub. You can also find us at pinniped.dev and we're active on the Pinniped channel in Kubernetes Slack where I have had you two licensed open source projects for anyone interested. Thanks for coming. Thank you.


We are blessed and lucky to be chefs in South Australia Where South Australian dining is is on top of the world with everyone is we have these young chefs We have amazing little restaurants We actually get the easy job in the end of the day because we just cook this beautiful product We have this philosophy of our food here that we find the best produce possible in the state And we don't do anything to it We let the product sing for itself basically and talk for itself It's like all the fruit and vegetables we get are from Waker in the Riverland. It's only 40 minutes up the road It's sometimes I don't want to let people know that you know, we have the best product in Australia So it's a beautiful story from a farm to a plate that we showcase here


In this video, we're going to explain how computer systems encode integers, which of course, as we saw before, they have to do that in binary logic, zeros and ones. So in order to encode integers, computers use two approaches. The first one is fairly intuitive. Suppose we have to encode the number minus 56. We can approach this problem from a very trivial standpoint, which is this is a sign which is either positive or negative. So it's only two possible values, which are very easy to encode. We could use one single bit and encode the plus with a zero and the minus with a one. Once we have decided this encoding of the sign, then we just need to encode this other number. But this other number, as we know, we can encode it as a natural number. In other words, using regular base two. And if you do the operations, this corresponds with the encoding 111000. Now suppose we want to use this scheme and encode our integers using, and this is very important, 8 bits. If we use 8 bits, we know we're going to use one for the sign. So in this case would be minus one. And then we need to expand this code such that it fills the remaining seven bits. In this case would be 0111000. We have to pad this result with an additional zero. So this would be our encoding of integers following this scheme. As you can see these seven bits here are encoding the magnitude. And this single bit here is encoding the sign. And this is the reason why this scheme is called very intuitively sign and magnitude. If we look at the type of numbers we encode here and we draw this representation of the integers, zero here. Suppose these are all the integers. We obviously are going to represent not all of them because they are infinite, but only a subset. So number zero would be here in the middle. The maximum number we can represent with sign and magnitude is actually a zero followed by several ones. As many as we decide the size of our encoding. In this example would be 8 bits, so it would be zero followed by 7 bits. On the other hand the minimum number, which would be this other extreme, the minimum integer we can represent with this scheme would be a one, one, one, all ones. If we decide to use 8 bits would be 8 ones. Now this encoding is very intuitive and the name kind of summarizes the way it works. But it has a little bit of a strange property which is what happens with the representation of the zero. And as we can see the zero right here can have two possible representations. Suppose we stick to our 8 bit size. So this would be one possible representation of zeros, but also this would be another equivalent one. Therefore we end up with two codes for the zero. And this is not very desirable. The other thing that we haven't explained is that once you have decided on an encoding you have to know the rules to perform additions, to perform subtractions, multiplications, divisions, etc. In other words it's not enough to encode the integers, but you also have to figure out how to operate with these integers. Okay so this is the first encoding we have seen. Again sine and magnitude. Very intuitive. However it has this undesirable property over here. Now over the years scientists have come together and realized that there are other possibilities for encoding. Let's represent again this line representing all the integers. Here we have the maximum and the minimum. Now one nice property of this encoding is that all positive numbers have the leftmost bit to zero. So we can say that this is the sine bit. This new encoding that we're going to propose now what it does is the following. It considers a unique representation for the zero, which is all zeros. And what it does is all the negative numbers are going to be represented by the ones starting with a one in the most significant bit. But they're going to be flipped. They're going to be reversed. So this is the number minus one. Minus one is going to be represented in this encoding as all ones. And then we're going to keep decreasing this binary encoding until we reach to the minimum number. And the minimum number is going to be represented by a one, of course, because it's negative, followed by all zeros. So let's take a second to review this new encoding. Rather than having the numbers overlap with two codes over zero, now we only have one single representation for zero. And the only other counter-intuitive property is that the number left to the zero, which is minus one, now has all ones. Another way of looking at it, the negative numbers now are encoded by these increasing values from one followed by all zeros all the way to one one. But it's starting from the minimum to minus one. Now this is, like I said, a little bit current intuitive. So the question is how do we encode a number with this scheme? In other words, if I have an integer, how do I translate it to this new encoding, which by the way is called two's complement? How do I make this transition or this translation? As a matter of fact, there are a few rules that are very easy to apply. So let's work with an example. Suppose I need to translate the number minus 56 from integer to two's complement. The first rule that we have to apply is if the number is positive, the encoding is the regular binary encoding that we apply for natural numbers. So we only need to worry about specific rules for negative numbers. If we have to encode or we have to translate an integer, which is positive to two's complement, we just take its natural representation and that's it. Now for the negative numbers on the other hand, we have to apply three steps. The first one is to convert the magnitude to binary. In other words, 56, forget about the sign for the time being, we have to convert it to binary. And we saw here in the example that 56 is one one one zero zero zero. Now we're going to assume that our integers are representing with eight bits and therefore our correct result needs to be padded with two additional bits here. Zero zero one one one zero zero zero. So this would be a step number one to convert minus 56 to two's complement representation. Step number two, careful with this one, is to flip all the bits. So the representation, instead of being zero zero one one one three zero's, we go to one one zero zero zero one one one. And step number three, perhaps the most important, we have to add one to the result. In other words, we have this number, we do plus one and we perform this addition, which is one plus zero. Sorry, one plus one zero one plus one zero one plus one zero zero plus one one and then zero zero one one. And these we obtained here, the representation of minus 56 in two's complement. So again, repeating, whenever we have a negative number, only negative numbers because positive numbers are represented as regular naturals. When we have a negative number, we convert the magnitude to binary first, flip all the bits, add one. Now, this encoding has a very important and counter-intuitive property. Suppose that I have to encode now number 12. Now as I said before, coding number 12 in two's complement is trivial because the only rule that applies is I encode it as a natural. And again, since we're using eight bits, my representation is going to be zero zero zero zero one one zero zero. So this is represented number 12. Now here comes the most important property of two's complement. What happens if I want to perform this operation? Minus 56 plus 12. So this is basically operating regularly to integers. We can do the operation right away and we know that the result is minus 44. But now look at what happens here. What happens if I take these two binary codes which you'll agree with me are the two's complement encoding of 56 and 12 and I directly apply the regular arithmetic rules of addition. So I add the two numbers. If I add the two numbers, I obtain the combination zero zero one zero one zero one one. Again, this is the result of adding the two binary representations of number minus 56 and 12 represented as two's complement. Now let me use this combination to apply the reverse translation from two's complement to integer. And again, we have to apply three steps. So let's take this example and apply three steps. Step number one to obtain the integer from a representation in two's complement. Which again, it requires only special steps if the number is negative, if it has a one here. If our result had a zero here, then the translation would be trivial because it's just two binary two numbers which you directly translate to the corresponding positive number. But since it is negative, as in the case of this translation from integer to two's complement, we need special steps. And the steps again are three. First one, you flip all the bits again. So this number becomes zero zero one zero one zero one one. Step number two, you add one. So we put a one here. Perform this addition. One and one is zero one and one is zero one one zero one zero zero. And now step number three is translate to natural. We need to translate these numbers to natural. But as we know, this is the bit with weight two to the zero. So this is one two four. So it'll be four plus eight 16 is zero. We don't add that one 32 zero and zero. Therefore, this number is 32 plus eight plus four 44. But we started with a negative number. We know this. Therefore, my result is number 44. Now here is the most important property of two's complement, which is if I take the representation of two's complement of two integers and I apply regular addition rules for arithmetic, regular arithmetic addition rules, the number that I obtain corresponds precisely with the two's complement representation of the result as we have proved over here. The only thing to take into account is that when the numbers are negative, the translation of integer to two's complement and two's complement to integer, they both require these three steps, which I suggest you practice so that you can remember them by heart. Now to conclude, this is actually the preferred representation of integers. And it's mostly for three reasons. The first one, most important one. Addition rule. Addition rule refers to the fact that I can use regular addition in the two's complement code and it works perfectly for integers encoded in two's complement. Second rule, I have one single code for zero. This is very important. The code is more efficient because I do not have this duplication that I used to have here in sine and magnitude. And finally, another interesting property is I still preserve the sine bit. In other words, every integer encoded in two's complement still preserves the property that the leftmost bit or the most significant bit represents the sine.


Three, two, one, go! That's here? That's here? Position goes on. Keep square with the use. Time! Four and count. You are tied up. 40 seconds to go. National finals. Ready? Three, two, one, go! Three, two, one, go!


We may as well make a start. The rest of our panel may walk through the door in a moment. If they don't, we have more time. That's good. My name is Paul Miller. I'm going to be moderating this conversation today where we're going to learn a little about real enterprise experience of really using OpenStack to do production workloads. One of the things we're keen to do is to get audience participation, to get all of you involved. If you have questions or comments as we speak, please do contribute them and we'll get a conversation going and hopefully learn from one another. The other thing I have to say before we start is that Alison at the back, taking photographs, has said that everyone who is here can have a t-shirt at the end to reward you for staying and for contributing and for sharing your perspectives. If you see Alison at the end, she'll give you a voucher which lets you pick up a t-shirt from the Intel stand. So let's get going. As I said, my name is Paul Miller. I'm going to be moderating the conversation. I have an esteemed and rather small at the moment panel which is going to get bigger in just a moment, I promise. Yes. So I'll let our existing panelists introduce themselves. First off, Carmen. Good afternoon. My name is Carmen Rimi. I'm a director of cloud engineering over at Workday. Workday is a successful software as a service company focusing on HR and financials and other products over time, including big data. Good afternoon, everybody. My name is Patrick de Busescaire. I'm working for Numergie. Numergie is a public cloud company. We started two years ago. We are fully engaged with OpenStack and I'm going to tell you what are on the road. Nicely, we said journey, but the journey is going to have some rapid. Rapid is something we need to mitigate. So that's the return on experience we're going to share with you. And I hope you're going to have a good time. Thank you. So sticking with you, Patrick, what are you using OpenStack itself to do? So first of all, I mean, when we started two years ago to build a company, we were thinking about the visions. And when in terms of visions, we were defining should we have vandalock or do we have to think different way. And when you said different way, what kind of decisions regarding the risk, we're going to be able to assume. So we started to think about OpenStack. It was the early days of OpenStack, but there is some very true experience coming from Rackspace and others. So it was inspiring me somewhere and the team and said, OK, if we go to OpenStack, which release are we going to start? So we were willing, I mean, Grizzly first, and we're starting with Grizzly right now. We are I South, very close to move to Juno. So Juno will be probably on the early stage of next year. And I have to tell you that we got the breadth of the foundations. It means a lot of innovations coming from the innovations from everywhere. And we see it also during the first year where we decide to go with OpenStack to see the big player coming in a game. So big player, you know them because they give you a lot of t-shirts, caps and others. But the big players, it's another things to think about. I mean, is it solid? Yes or no? Can we think about, I mean, an engine would deliver services to company and those companies could be stock exchange. It could be very young company, which are looking for services and paying the services only when they use it. And we think that OpenStack was the right way, I mean, to go with, to think about the new infrastructure service. And our platform is commercially available since last June. It took us a year and a half, I mean, to design, to prove of concept. And finally, we were going on the road with five partners, which has been to criticize our jobs, the design, and they get the confidence in numergy and the way that we have implemented OpenStack. So I will tell you how, when and what was the big issues we were fixing and we have fixed. So, just sticking with you for a moment, now you were essentially building a new company, trusting OpenStack. Now, OpenStack grisly wasn't the most dependable piece of software to launch a new company on. So that was quite a leap of faith. Yeah, you say in English, mitigate. I like this word because we don't have the equivalent in French. So mitigate means that you are taking risk and you are looking for the value. I would say we find the value, but also we find some other things than company you are dealing with for many years should I have to buy or should I have to make. And that's a big, big, big concern as a CTO when you're borrowing to the team and talking to the shareholders, then I have to have their confidence. They know that they are looking for cost, means that license or software is not an issue, it's an option. And we were, let's say, commit to say, with good engineers, with good schools, engineer schools, you can get the best of breed, but also you have to think about release management because this market, it's not only skills, but as soon as you develop the skills, competitors are looking for you. Not only to use the platforms, but use the skills you develop with. So the risk, it's financial, it's about skills, and it's about partners, good partners to deal with. And for France, OpenStack three years ago was an interesting journey again because only one company was obviously satisfied to talk about OpenStack and the rest of the market was much more, I mean, two-PC talking with OpenStack. So when you said, I'm going to sell to EDF as we did with a good partner and I'm going to tell probably some words about HP because we were working with them and designed the CloudOS on the early stage and the French company, as numergy is, bring the inspiration to a very large company and said, okay, if you want to operate this way, you're going to go directly to the world. So it was the right combinations between big player, small player, bring the energy, bring the visions and finally how we want to operate for customers infrastructure as a service as a public cloud. So that was the big questions we fixed. I think it solved for the time being, but the next release and after release, it's always another game and that's where the topic is about release management because release management from OpenStack is quite an interesting one but when you talk to very large company, I mean they are doing release management every six years and we get every six months. So how do we fill the gap? Yeah, and that's the topic we want to dig into a little in a moment. Workday, what are you doing with OpenStack at the moment? At Workday with OpenStack, we've had integration paths for quite some time. We allow our customers to submit workloads, Java workloads that we run in our cloud and that was one of the very first workloads that we've used to migrate over to OpenStack, leveraging the existing sort of virtualization technology that's already there. We're also looking at the whole breadth of our workloads at Workday and in the fullness of time the hope would be that we use OpenStack to run the entire data center as a combination of ironic, a combination of KVM and then also containers. So each of those models were and when appropriate. So I mean for both of you, you were taking a risk of one form or another in moving to OpenStack. What was the evaluation process you went through in comparing it to some of the other ways you could have solved the same problem? Start with you. Sure. So at Workday, we are a couple of different things actually. We started even with evaluating operating systems, Ubuntu versus CentOS. We looked at different network options, different storage options and each of these major pieces within OpenStack, even Compute, we're looking at containers versus KVM. For us, the two, maybe three fundamental things are, does it work? Which isn't always the case. Does it perform and how secure is it? Obviously you have engineering teams, smart people, dive into those issues and tear it apart, put it back together and come to a decision, converge on what works best and then move forward with that technology. That's kind of what we did at Workday. Yeah. As a public cloud service provider, I mean the two big issue was should we have to virtualize that's okay. Everything is agreed on that. But what kind of virtualizations? And as Kevin said, what kind of kernel I should deal with? There is a lot of options there. So you can decide to build your team, which are contributing to the Linux foundations. That's one option. The other one, it's looking for what is available on the market. So you should talk to your engineer teams and they have multiple ways and multiple feelings to say that's a good one. That's a really, really, really best one. And at the end, when you are looking for, you think about what kind of supports I need. So that's exactly what Kevin said in a very political way. Nice. The other things where we were very, very sensitive was the networks because if you say that my revenue coming from the public cloud, you should have a network. With no networks, you have a very nice platform but nobody cares about it because nobody can use it. We were adding another point at Numergym, because we love things which are complex but under control. We are saying to partners, we don't talk directly to customers. Of course we are going visiting customers with the partners, but we don't sell directly. We don't have any shops on the internet only for the very small and limited VM. So is it open stack or not? It's a bad cost. So choosing QVM and which QVM is the best one. And when you think of the best one, is it my choice or the company which I'm targeting as a customer will tell me what is the right choice. So bundle the kernel itself and the network piece because probably everybody knows then the first network model belong to the open stack. Folson, Grisly. It was unpredictable in terms of stability and I'm very, let's say, clever when I say that to you. Everybody are thinking about the network piece. It's extremely important for a cloud service provider as we are giving the network access its key because it's about revenue for us. It's about also customer experience and it's about flexibility. So we were very committed to say network will be happen at Numergy only if it's virtualized. So we were picking up on the early day SDN. And we have implemented SDN with the weakest piece of Neutron or Cantrum depends on your failures. And networks has been really implemented by Numergy so we are using SDN from Nuage, Nuage Network because we were directly linked with the labs. We're getting the very, very late fresh driver and we were operating also a canonical kernel. So those three elements bring support. Even to support it's quite difficult to explain when you get an issue because everybody is looking for what I did there, what kind of documentation is available, et cetera, et cetera, because you are running fast. You should focus on the business and also you should focus on what should be controlled. And that's the numbers of conversations I got with my colleague is there. It's about productions because it's nice to design to the driver but at the end it should be operational control. So that's the main piece we were focused before to say, OK, OpenStack is the wire road for us because we believe that with OpenStack we can run multiple instances, we can have multiple hypervisors and in Numergy we said we want to produce the digital energy for today and tomorrow. It means that the engine has to be very solid, very reliable and significant also in terms of saving your cost for customers. Did you look at things like Open Nebula, which was perhaps bigger for the European part of the audience, they may be more familiar with it than the North Americans? Well, I will talk only for my name. I've been working 25 years for independence software vendors. So I was much more copyright oriented and I can share with you the big difference I've lived since I joined Numergy. Open source is just incredible but what kind of workload the customer is waiting for and that's my experience. So it's about knowledge, under control knowledge and picking up what should be done to deliver the best service. So think simple, which is not the right way to think open source because you have so many options to code. So adopting for us some agility in a way that we are producing a lot of new features or we try to. That's also something we want to manage as a cloud service provider because you know that we are compared with a very large logo in US one which has billion investment per year. So we are not poor, it's about million but those million has to be revenue somewhere. So working with open source I think he was refreshing what I learned during the last 25 years. I know that everything is possible but at the end I mean it is possible for the right go to market and also if you don't think the complexity you are not able to fix tomorrow you're going to get to fix it tomorrow, after tomorrow. And as soon as you launch the service and customers rely on the SLA you should be very serious about that. So what about you in terms of the other options you looked at before settling on OpenStack? So we had before settling on OpenStack we had our own inbuilt in house technology but also when I joined we looked at Eucalyptus and CloudStack and initially just started with a paper evaluation setting up some criteria that we thought was important to us of course momentum and openness and those kinds of things were a big part of that. The architectural quality as well and the direction was very important to us and so after that paper evaluation we did do sort of hands on hey how does this actually work in the wild and we did that with CloudStack and OpenStack and at that time and this was back in the grizzly time and just before that we were just a lot more comfortable. So CloudStack won? Absolutely, absolutely. And I'm just here to convince you guys all to switch but no, OpenStack won and obviously we've been both pleasantly surprised with the continued momentum but also as Patrick mentioned it is sort of a journey to get to the point where you're ready for production workloads on top of this and the open source aspect of it but beyond that even the open community really important for us and you know from the storage you know we're using stuff on the networking side we're using Conrail and all of these things have come together for us I think quite well. Good, thank you and if anyone in the room does have questions please do wave your hand if I can see you through the glare of the spotlight I will draw you into the conversation and while we're going on one of the things that a lot of enterprise clients especially are talking about and grappling with is this question of whether they take OpenStack from trunk or one of the distributions or a distribution and support what did you two decide to do? Well for us we're using the packages from RDO but it's pretty much our own what we put together sort of shift cookbooks and we've invested a lot of time in our continuous integration continuous deployment technology so that we know that as we take up new elements whether it's from the open source community or from our own contributions we're able to test this in a way that we have a high degree of confidence that we can push it out there similarly I'll add that within our data centers leveraging availability zones quite heavily so that our application developers and our platform teams that work on top of OpenStack are able to take advantage of the availability zone paradigm so that if we screw up and take an availability zone down which is going to happen that their service doesn't go down and they don't suffer sort of an outage. So for us again I will insist because we are a service cloud provider operated only in public through partners security is always the first topic to cover with any partners or or customers you know that Numergie is born from a public initiative, it's called Andromed it was about three years ago and the idea for the French government to say to the market then we need some actors we need some data centers in France we need to protect data because some could be export but some are not able to be export for many reasons I'm not here to explain why they are okay or not but that's a concern, that's regulations so we should assure to our partners then we are very serious about security so we build the security operation centers to protect the data centers but the platform also everything has been encrypted everything should be VPN everything should be load balancers so that's a very classic concern for any type of customers but the first topic we should prove and that's why we are running this year I mean the certifications to get the 2701 but also the CSR stars that's another way to say what I said it is writing, it could be checked so security it's a big big issue when you are public platforms and especially if you display on the flag that this is open source because for a lot of security officers open source means backdoor they have the same feeling about the corporate but they have to accept it because they cannot control so at the end I mean security is it a concern? of course it's about confidence it's about confidence you bring to customers but you bring also to partners that's another way I mean to be compared regarding the others players on the market and I think the merger did a very good jobs in terms of security we continue to invest in security and the French security offices are checking our infrastructures not to check if we get backdoors but if we are very serious in terms of security vision, approach process, techniques software, equipment data centres all those layer has been scrutinized and right now we are very secure but as soon as you say we secure I mean you are tired a lot of people which are looking for is it true yes or no? it's a challenge isn't it? so keep you alive every day and sometimes you will start to sleep at night also so for both so for both of you then you're saying that you wanted to retain the control and the knowledge over the code that meant you wanted to do it yourself rather than taking a distribution or someone else had taken on those steps no we were contributing to Solum we were on the top one just before Rackspace so you know that Rackspace has built OpenStack so as a very small company born in Europe we are very proud about that but Solum was heavy attractions some months ago and is moving so I would say OpenStack or Open Source is every working ways that you too selling that it changing very very often and as a CTO when you said I'm looking for for the next three years you should keep up the ship where it should be with the right cap and that's something you need to mitigate every day with your teams with the providers and also about what you learn because on a journey we learn a lot of things so we know that because you are more and more popular I mean the attacks is coming from very often I can share with you that we are storing 4 billion message per day only for the security the good things we're going to do big data on that and we're going to sell out services about security so that's another way to learn on a journey that things you are investing could generate return on investments but you should be patient and the board of the writers should accept also that's another part of the job so that worked a probably very similar in terms of having probably not necessarily control over what's going in there but we have a lot of best practices and a lot of existing technology at work day in terms of how we manage our data centers presently and so a lot of this work is integrating OpenStack with those existing things whether it's telemetry or logging or security appliances you name it there's a lot of stuff already in place and so there's an imperative that we integrate this technology with those existing technology but also to operate this you need to have a high degree of familiarity with what's happening beneath the covers we don't allow anybody outside of the company inside of our data centers and so something breaks we've got to be able to fix it and so that traditional path of ramping up on the technology figuring out how it breaks and how to tear it apart was a critical element in the maturation process for us so for both of you that path creates an immediate challenge which is skills where did you get them from did you train up existing staff or hire new staff so this is a brand new team at work day we did leverage some of the existing in-house expertise where we're applicable but just hiring new employees and investing in the new employees making sure they're as you'd expect smart high bandwidth that can learn technology quickly are comfortable and flexible with requirements that might be vague and able to learn with these learning technologies able to contribute maybe not right out of the bat but within a short period of time so what do you hire do you hire an open stack engineer or do you hire someone who understands asset of technology our focus has been on software engineers and software engineering people with computer science degrees we have a lot of sys admins and people familiar with IT infrastructure at the company and then bringing on software engineers with that sort of sys admins and bent was the path we chose Patrick we were following two roads first because we started the company so we were looking for to hire people as I said the availability were very rare in terms of real open stack experience we found some people which has been experience of open stack ccs that's okay that's a proof of concept for yourself when you are home and you are thinking that you could do something interesting at home but it was not at the right level I mean what we were looking for so we were forced to looking for people then we gonna train and I was loving this period because we were picking up some doctors coming from when I said doctors we respect because they have a very large brain and they can read, learn and express and train I was following what I learned when I was in US I mean train a trainer that's one way it was enough to build an architect teams about seven people but you have to find a very senior one which has not a dreamer it's over it continues to dream but he's dreaming to build a team much more than getting more value on the market so that was one part of the planning we were thinking about and we were doing but the other ways we were working were we were deciding to talk with some school engineers or engineer schools especially for the last four years before they get the degrees or the certifications so we were building with the team the cloud certifications from some specific schools we have around Paris two of them and the goal to get those engineers because we were showing the project we were training them about cloud not only especially open stack and that's another way to getting the best of brain in terms of new engineers because they are still dreamer and I'm going to be a dreamer again but also I can tell you to manage those people you should to relearn all the time what you learn what you think it is true because the right way to manage those new energy it's a big gap for company so you should accept that they are coming from with skateboard you should accept that they have doing some flash ball I said not dead behind that but sometimes I mean during the day I mean they can get up and say okay we are going to play for 10 minutes or 20 minutes so the breath for those time of team is very different and you should adapt what the board is thinking about it and the right way I mean to put a new atmosphere where you get the best of the innovations when you are senior as I am that's a new lesson but I like to learn and it was a very very good pleasure I mean to work this way so we blended some seniors, some doctors some brain new engineers which are not be yet certified but many of them has been joined in numergy that's another way to get your people very loyal and that's something we need to build a culture because everybody is thinking about Silicon Valley but you can do that I mean around Paris and that's a very good experience returning experience I'd add to Patrick mentioned with interns at least that's what we call them in the US and new college grads we've had a lot of success identifying them from some of the top schools bringing them on and that has a snowball effect as you bring these students on and they go back to the university to get additional candidates coming at the next opportunities and that's been a tremendous experience for us we're a start-up in Switzerland we're going to be providing public cloud as well we went live beginning in November and we're looking to make our cloud GXP compliant and I was wondering if either of you have done that and how difficult it was to get there I'm laughing but it's serious not for us which part of Sweden are you on why are we in Basel ok so I'm currently talking with some bodies in Zurich but it was not for the same subject you just want to get our our open stack platform oh no we've already built ours it's ok we're done but we didn't get to this level probably we need one part of let's say the radar we want to be certified we want to certify for France the open stack with a classroom with a very high skills to get these certifications as a big player did for many years I mean I think about Cisco and others and that's another way to bring the people and getting the confidence from them so we are thinking seriously about that and that's something from the market perspective I mean if you want to see switch the big bang on Twitter and others they have to think that the training course the certification and the platform and the player are available because they want all in one answers and that's somewhere the strategy following for us for my English that's ok it hasn't been a focus for us no ok something you feel you have to have definitely in Switzerland it's pharmaceutical companies and they're not going to come in our cloud if it's not GXP compliant we've got all the training that's all sorted we're moving on weight we've got ISO 9000 and one sorted we're going for 27000 that's almost there GXP hopefully next year but I was just wondering if anybody's already done it because there's not a lot of people who have and so it's a little bit of a blind alley we're sort of crawling along in the dark so when you've done it come to Vancouver and tell the audience about it hopefully yeah I had a question something of course to pop to my ear when you said cookbooks and two questions for both of you but the cookbook one first you hopefully realise there are open stack cookbooks out there in the community in Stack Forge right that are now maturing on one of the course so I have to nibble on that a little bit have you ever tried to contribute back to it and who might be doing that and then just in general you've taken open stack I'm kind of curious what type of what type of parts have you done for giving back to the community I'm just kind of curious how that's scaled in both your companies I can start with that we started with the rack space cookbooks where that's what our earlier clouds were based on we did go down a different path in some of our production deployments we do have an initiative right now to use the Stack Forge cookbooks and I believe we've made some contributions back already but we're just at the early stages of that and our future production clouds are most likely based on Stack Forge I am curious to see whether or not any work is being done to do Stack Forge with triple low just because of my own belief triple low data center scale installation and upgrades somehow that should all roads should go through that someday but as I said perfect I think I answered the question so as I said we were contributing to Solom in terms of cookbook I'm quite jeopardized because when I was talking with my people a year ago everybody said puppet six months later they said chef and right now they said Ansible so sorry to share with you one secret I got a musician so that's only way to writing music so I like to change technology but at the end I think about three years if I change all the time I mean what I add in it's complexity for my colleagues are working in productions and that's my big concern so I don't care about Ansible or puppet or chef I know that we did it as soon as we have to contribute or to reverse what we develop but what I did in terms of internal rules every of people of my team can contribute but they have to contribute in the name of numergy and that's something you need to balance because people are dreaming about themselves which is cool but did they have to do things that the company is looking for to develop? yes or no so I put it some rules I learned in my copyright word I said you contribute in the name of numergy means that you have ethics wide way to document and also that's another way to say that numergy is an innovative company energized but the good engineers but this is not an individual contribution so puppet, chef I don't know and I'm waiting the next one and it's confused somewhere what is the best for the next three years that's a big question you have to ask so when you are swimming in the swimming pool of open source for years you don't see any issues but what I see if I'm thinking in the next few years I have to keep up the code which has been developed 10 years is it something you think about it when you are doing? so this raises a broader point that we wanted to touch upon we only have a few minutes left but you talked about the move from puppet to chef to ansible and also at the beginning mentioned the issue with open stack release cycles they're rapid every six months something new arrives it's okay perhaps for a developer it's okay perhaps for dev and test it raises issues for both of you in terms of running a mission critical dependable product definitely I have no words to say it's interesting for the test and dev for sure but how many company as developers in ours have their own applications because most of them have been moving in offshore it seems that the developer is now coming back on top of the concern but we have to help them to pick up the right tools for the next five years and the next five years with every six months on your release it's a very difficult forecast so you should be in that's why the energy is one of the contributors and we pay to be part of I put my engineers or the team on the key critical compartment we need to operate the platforms so security network, storage and of course CPU or calculation nova and also the storage it's a one piece we're driving you to the big data area space that's also a big concern you need to balance what kind of technology not only for the timing but if you have to move 10 or 20 peta what time I need to move from one way to another one which is the same data which have to have the recycle to put it in a new web because you want to extract the value of so that's a concern you have to have to fix in terms of CTO because your role is to define what should be done how we can do that with which budget and at the end for which customers and are starting always by customers I don't know what the customer want to do with big data but I know that they want it that's a common respond to think everyone wants big data but they're not totally sure what they want to do with it the six month recycle doesn't bother us as much our current strategy is probably six months behind the latest release once it's been vetted and had a .2.3 sort of upgrade and bug fixes and things along those lines and then we'll let it incubate through our continuous integration process and then go from there good thank you so we are I'm afraid out of time I would like to thank my reduced panel that they did very well talking for what they thought they thought they would have half the time to speak that they actually had so they filled the space nicely thank you to all of you for your attention and for your questions I hope this was useful to you and Alison will give you vouchers for t-shirts if you want the one on the way out of the door so thank you all very much for your attention


Hi guys, welcome back to the channel, it's Meks from the Meks creation, if it's your first time come across this channel, yes give us a thumbs up, give us a sub so you know we are looking at a road to 5000 subscribers, at least by the end of this year, yes guys support this channel, support me, let us try to be a team, we are a team and being able to make it from the start, at least we need 5000 subscribers at the end of this year, in today's video we are going to look at the tips to follow before coming to the UAE because we are talking about the changes that are coming in the UAE, the changes that are already existing in the UAE, first of all we want to look at deportation and people being deported from the country back to return to the country, yes those are some of the changes that are signifying that things are not going to be the same, so in today's video we are going to look at the tips to follow before coming to the UAE you know people who want to work to the UAE for the purpose of work or even what you call the investment reasons or even other legal purposes should avoid what you call visa free or they should avoid being exploited or being deceived of the availability of visas of what has been existing so we are going to look at what are the following things or what are some of the things that you should follow when you are planning to come to the UAE, first of all if you are offered what you call a job in the UAE you must get what you call an offer later, that is the latest information, if any company is giving you a job in the UAE make sure you get that offer later that offer later should be authenticated or should be issued by what you call the ministry of human resources and emitterization, it should be thoroughly stamped, then two you should also the employer can also verify what you call the job offer validity in the UAE either you can use the embassy in your country the UAE embassy in your country or you can still verify that job offer on what you call online, I'll give you the link where you can inquire whether that job offer that is being given to you that company is a genuine job offer those are some of the changes that we see then still something we look at number three that after you sign that offer later this company that gives you that offer later after you accept the terms to sign that job offer later it will be returned and unemployment visa will be given to you to enter in the UAE then number four something that you also need to know that the visa visa or the tourist entry visa does not give you the right to work in the UAE that is the latest development that is happening before we used to see people coming with the visa visa the old job and change it immediately but now it is not allowed it is illegal it is illegal and anything that will be got against you it will be against you in the courts of law and with what you call the penalties then also something that you need to know that in the new law or things that you should know also coming that the new law your employer should be responsible for payment of what you call the recruitment expenses in the UAE level normal payment of the recruitment agencies that we have been paying recruitment fees that we have been paying to the agents now it is supposed to be your company that is recruiting you giving the job offer to make sure that everything is paid up from your visa and air ticket until you get through that place of work where they are going to recruit you in that way then number six something that you should know that make sure that that company exists I told you you should make sure and to check whether this company exists in the UAE or it does not exist and what normally you can do you can definitely check on what you call the economic the national economic registry where we have a list of all companies or entities that are working in the UAE so probably when you go to those searches and you are punching the name definitely they will give you all the details of those companies in the UAE then you can definitely know whether this company exists or it does not exist in any way or the other then also something that you need to know in case there's something that you don't really understand there's something that you feel you don't understand out of what is being given to you to for example the job offer or the contract you can still inquire you can still make what you call inquiry that is from the ministry of human resources and email using you can either using the phone number that I will give you also below you can also use what you call the email address you can still inquire something about what you call something about what you call these companies for you to get what you call the real information or to get the information that shows whether this company is genuine then also something that you should also have is that you should also be issued what you call a raises permit or the visa and this visa should also be verified is validity this visa that you're given to to enter into your UAE should have a validity or should have its validity and you can as well also check on what you call these government websites whether to find out whether the visa is genuine something also that you need you need also to know that you can also verify you can also verify what you call the validity of that visa that is being issued to you from either in any Emirates that you are in if you are in Abu Dhabi, if you are in Indonesia, if you are in Jumail, if you are in Kwaumkwimin, if you are in Pardijain, anywhere you are you can still verify the validity of that visa or work permit that is being given to you is being given to you by what you call that employer then something that you also need to know that now the new changes is that the tourist visa can also be issued by what you call the UAE based airlines when you talk about the best airlines we are looking at those national carriers the airlines that are operating in UAE for example ETIAT ETIAT then we look at Dubai then we look at all those other airlines they can also book through what you call the agencies and hotel in one way or the other then something that also you should know there is nothing called like what you call any independent employment visa some of us or some of people been going to Dubai and they have what you call what you call an independent visa where you can have it your own you can move and do whatever part time of work in any other now that one has completely gone off you never have something like unemployment, independent employment visa all employers or all employees should be working under what you call a company and it is only that company that can give you a right either to part time to some other company or not depending on what we call depending on the agreement or depending on the contract that is being signed between the employer and the party in one way or the other then something that also you should know something that although when you are coming to UAE something that you should know what you call a residence visa cannot be processed for anyone while the applicant is outside the UAE remember a residence visa can also be issued can only be issued to an applicant inside the UAE having what you call enter the country on what you call an entry permit if you enter with what you call an entry permit or twice visa then they can try to apply for you a residence visa and you can still get what you call your ID in one or the other hope I have tried to share something for you you know we are looking at the visas in the UAE we are looking at the latest information and this is exactly that you need to know you can share up to your friends you can let them know such that you don't have to fall in another trouble that has been happening hope I have tried to enjoy something share something with you thank you so much and see you again in the next video this makes me next creation to you


We just need to show people how to use these things. Showing them recipes, how do we make it easy? Like, maybe we put a QR code on it. Very promptly, everyone's like, no one uses QR codes, don't do that. COVID happens. People use QR codes now. Like, can we do the QR code thing? Not only showing recipes, but we have textable shopping lists. You click into a recipe, like a ginger and miso roasted salmon. Like, oh, that looks good. You can click Text me the shopping list and while you're in store, you get the shopping list. We don't use content to sell our product. The content is part of the product because we need to be educating consumers.