Thanks. Welcome, everyone, to Cloud Foundry Day at the OpenStack Summit. Today, I'm going to be talking about containerized cloud foundry on Magnum. And it's going to be mostly about containerizing cloud foundry, and then about getting that particularly onto Magnum. My name's Jeff Hobbs. I'm the director of engineering in the SUSE Cloud platforms area, specifically focusing on cloud foundry and container technologies. So a little bit about what we'll be going over. One, why are we here? Then just about containerizing cloud foundry, using it as a Magnum as a base, then putting the cloud foundry on top. Then I'll talk a little bit about where our current state is and what we'll be doing in the future. I've set it up so I can talk mostly through this. There's about 35 slides. And then I've got a CAN demo that we'll get to because, unfortunately, the front to back, it doesn't all happen in the five minutes. I claimed that it took earlier today. So first, why are we here? Everyone's looking at this. A lot of people are working on their application and environment transition from regular data center stuff out to the cloud and their apps moving from physical servers to VMs to containers. And all of this is in the long term, hopefully, about microservices and improved development process. And I'm at SUSE, where does SUSE fit into this? I'll note that we'll talk about the whole idea here. We're really only talking about the top right corner, where it says cloud foundry. But all of these are elements of the SUSE stack. All of these are open source. So all of these elements you can play with right now, if you want, and we'll be talking a little bit more about some of them as they touch into cloud foundry, containerizing, the obligatory container picture. So first off, who here actually runs a cloud foundry installation at any level? So most. So cloud foundry is usually deployed using Bosch. And in a very simplistic way, Bosch is a tool chain that tells you basically how to organize all the code for your software so that it can be easily deployed. The specific aspect, though, is it deploys to VMs, where you look at cloud foundry and ever since its very version 1 instantiation, it had a pretty clear delineation of what the processes were. In fact, many of them, you could argue, were almost written in a nice 12-factor way. Yet still, the standard way in which deployments happen for cloud foundry is always to this VM infrastructure. And we wanted to deploy stuff to Kubernetes. So we wrote this tool. It's called Fisile. And it basically converts all these Bosch things in the VM-centric of Bosch stuff into container-specific implementation so that it can be run on Kubernetes, which means Fisile knows how to automatically compile, configure, and run all of cloud foundry. The nice side effect of using Fisile is that it gives you the mechanisms to make your deployment easier also for the end user and allows you to deliver all these compiled bits in the form of images in a much more ready-to-run fashion. And we'll talk a little bit more about that. So you're allowed to filter to what the user can really configure rather than the hundreds of things that Bosch gives you that some of these bits are very important to Twiddle and others you shouldn't touch. And the images ended up being configured after Fisile configured just using environment variables, like a 12-factor app would be. So the other aspect of it is everything that's done here is done in a way that maintains the cloud foundry foundation certification. And I'd note that Fisile, the Bosch disintegrator, and a lot of people have looked at it. It's kind of anti-Bosch. Well, it's not really. It's an alternative that actually builds off of a certain state in the Bosch lifecycle, the configuration lifecycle, and stops where it starts to think VMs and breaks it apart to think in containers. And it would be great to bring that further back, but I'll just talk more really about where we are now. So first off, why can't we just use Bosch? Well, Bosch is about virtual machines and that's not what we're targeting. As you kind of look around and you look around at the interest level of other people at the conference, you see that containers are more and more interesting and more and more important. And we wanted something for containers and container-based workloads. There's nothing about cloud foundry itself that prevents you from operating it in a containerized control plane. But Bosch does not operate that way. And also for science, because we like to play with things. So let's get into what it is in teasing all these bits apart. So first of all, it's about separating all the things. Over time, cloud foundry, which existed before Bosch did, then cloud foundry was Chef deployed and then Bosch came into being and they became very tightly coupled. Cloud foundry components are generally composable and have well-defined boundaries and APIs. But ironically, those lines between Bosch and cloud foundry become blurred over time as people have become dependent on using Bosch for the deployment of cloud foundry. And the other aspect is that these ERB templates and Monit have become embedded a lot into the entire deployment aspect of a cloud foundry system. And we don't like Ruby stuff sitting over and through the code that has to be used. And these ERB templates also contain control scripts, which are basically equivalent to cloud foundry templatized code, which are based on those Bosch primitives. They're not always cleanly, the most cleanly written logic and even some of those class definitions inside Ruby that seeped into the templates over time. So you've all of a sudden kind of intertwined way too much about deployment and just cloud foundry itself that doesn't necessarily need to be there. As we can see, as we will show. This also makes porting to other systems difficult. Now that is a debatable set. We're looking at it at containers and saying the containers have become more portable. But really we're bringing things up, just abstracting it to another higher level. And the fact that Monit's the only service statement that you can use is undesirable. And it's a piece that we haven't quite completely teased out of the system yet. Ideally you would do that in a truly containerized setup. So first off, what is in the container? We're basically starting from an Ubuntu 14.04 Docker image. And I say this ironically knowing that I am wearing the green shirt. We actually do it from other, from SUSE images as well. But the current certified system is Ubuntu based from cloud foundry heritage. Then you basically create your stem cell-like layer on top of it. This is very similar to exactly the way that Bosch is operating. But at this point then the adding of the packages and jobs happens at an entry point where we've now separated out. Has anyone actually dealt with Bosch at the template level? I've been on 40, oh you're all lucky. Where we have to then separate those things which happen at a compile time and which happen at the particular runtime. And then you can take what is in that container and decide to deploy it wherever you want. Get a little bit more about the building the world. So basically for this, again, we've taken a certain step, all the Bosch templates to the Bosch template releases are done. And we then take what happens at build time and separate it from certain runtime aspects. These are actually already separated in the Bosch YAML files where certain things happen at certain parts of the life cycle of the system. And we've taken the parts that need to happen at runtime and some of the compile time stuff and just moved that forward into container only operation. So basically all the compilation is already done when you're ready to run the system. In our case it's because it's in the container contrary to Bosch, which happens when you use your Bosch director to do your deployments. Also this is all happening in parallel because we're leveraging containers and go to compile everything with pretty much all of the cores on your machine for the creation of these containers. And it builds in again all of the compilation dependencies directly into the container. So those pieces of a Bosch system which say, hey, you have to do this, that and the other, we're kind of doing the same thing except rather than the VM, we're removing some aspects. And it's really not that many, it's not that far from being VM to being container based aside from a few key assumptions. And we're just making those separations occur so that we can have it all cleanly separated compilation when you're compiling in runtime for when you're actually starting up each container instance. And basically adding in a lot of smart detection of those various dependencies. So even if several Bosch releases with a lot of jobs that have a lot of jobs that you don't care exactly how they're specified, Fisile will correctly only build the things that are required for that particular role manifest. Sometimes some of these other dependencies that don't actually get run in that particular VM slash container end up in there. And Fisile is actually doing a true dependency check to see, okay, I'm only gonna work on the things which are important to the jobs. Again, the, I would say processes but it's not broken down to single processes but to kind of multiple processes that define the job of a cloud foundry component. So then next is going into the assembly line where you have the role manifest but basically before detailing what all the configuration looks like, let's talk about all that input. So again, as I mentioned before, we are taking things from the Bosch release manifest format. This is the same format that then Bosch takes as input and sets out to deploy and manage the life cycles in its, in VMs, we're taking that and then running it through Fisile which will then do the modifications necessary to say not VMs containers because then we put the container on the shelf and pull it off the shelf when we wanna do our actual cluster creation. So you could say we're kind of creating an extra intermediate step but that extra intermediate step is more pre ready to run with a lot of these assumptions that Bosch is asking you to either define or not touch but leaving in there to confuse you with the opinions to be already ready for use. So again, different Bosch releases, this allows us to be, we were building things off of the standard CF release format. Now we're moving to what's the newer CF deployment and these exist in multiple release forms so that you can have a routing release and you might have a different garden release depending on how you're doing your Diego, et cetera. Just represent some of the composable architecture that's behind the scenes for Cloud Foundry is remains composable in this setup. All that gets run through Fisile, as I said and then you get the Docker images. So a little bit more about the configuration and so this looks legible there. So the role manifest. This contains a list of all the Docker images that we want to build. You can co-locate more than one job on a Docker image and I'll talk about why we might do that in a second. Ideally, again, a job is a single or collection of processes that might run on a VM. Here we're running them on a container. It is not single process. It's unfortunately gone away from being pure 12 factor but this is kind of a step potentially in that direction for Cloud Foundry component definition. And so you can co-locate more than one job on an image from different Bosch releases even. And in the configurations section we transform those environment variables to the necessary Bosch properties. So again, the environment will feed into the container that at runtime only defines the necessary runtime Bosch properties you need for those jobs. And the opinions files are essentially Bosch deployment manifests with only the properties section and they contain basically the defaults for all of the things that, for example, a customer would never need to touch. The dark opinions shown in the bottom right corner is basically a failsafe where we're using it to insert and make sure that it actually erases the defaults on anything that may exist on the system. And then this is basically how it operates. You end up in the running and it executes the hook scripts, hook scripts coming from the Bosch side of things that need to execute a runtime. Config in, it's basically a sub project of fissile that processes all those templates and turns what are a lot of extra properties into only the properties you care about plus the environment variable management that should be, so all of the pieces that you care about plus the environment variables which should be the only things you really do care about and makes the runtime environment configured and ready. So then it starts syslog and cron and then monit. I mentioned before, we'd like to get monit out of this system, you could rely really on the container level management of readiness and things like that, but that would actually then, you'd have to change around the orchestration or fully change the assumptions of being able to run in bare metal VMs and that's obviously a larger discussion. So I mentioned this already around config in, but sort of configuration. One of the common complaints in Cloud Foundry is just how difficult it is to set it up. There used to be simpler ways than kind of Cloud Foundry grew and grew and now you can't barely get a system except for having 20 VMs and 60 gigabytes of memory and that is, there is Bosch light for some simplistic version of it, but there is a lot of configuration going on there. So the Bosch manifests are large and troublesome to deal with and I think that they're not really the most user friendly, the community would do itself a little bit of effort to take some of these efforts and hopefully separate out what are, it's kind of like what we're trying to do is if you ever worked in one of those properties dialogues and they have the advanced settings, you know, you maybe only have two or three things that you really care about and then there's the expert mode. That's what we're trying to do with this system because there's very few things that you really need to touch. In fact, I'd say less than 10% of the Bosch YAML properties that you could be faced with are actually ones that the end user customers generally need to touch and probably it's less than 3% you could do for very simple dev level setups. So config exists there to basically augment the whole Bosch template setup and provide for other sources of how to draw that configuration together from all of that giant JSON payload and the environment variables together. And we use some Bosch templates to eliminate some of that configuration complexity. A little bit on the configuration. So we looked at this, there's two ways, you know, the layer dynamic and layered static. In the dynamic sense, well, we could have had a console key space and it could have all this stuff in there. But there's a lot of problems but mostly being slow to run and you might have to restart it, it's not necessarily as dynamic as you think. And then it's requiring yet another key value RAF process. And when you've set these up plenty of times, you know that those underlying pieces like console and LCD are probably some of the most complicated pieces to make sure that in your distributed management and everything are set up right and everything on top of that just tries to work. So we tried to remove that by focusing more on a layered static and using environment variables for the user values and having everything else essentially pre-computed and stored in each container. So the only kind of negative of this is that, oh, if you find, oh, well, I actually did really need one of those other values, then you do have to go through, actually modify fissile to say, oh no, or config into say, I need to make sure that this one is user exposed so I can set it in an environment variable and then you end up rebuilding the world. However, in Bosch, you do the same thing and you rebuild much larger worlds when you have to do that. So all that said, we have the pull requests and they really focus on, and this is them and more, but they really only focus on a few areas. DNS lookup changes, hard-coded values that kind of were these subtle Boschisms and touching slash proc without restraint, which is a VM thing and something you wouldn't do in containers. And we've pretty much made, and most of these are all accepted, for removing these VM assumptions and dependencies from the system. And so, for the most part, a lot of this stuff is ready to see some of those changes move forward. And so we talk about, so you can see the fissile project, it's actually open source, it's on the SUSE GitHub. There's another side project of this called CFSolo and I mentioned before that you could actually co-locate more than one job in a container and this is basically taking fissile to the extreme of doing all of the configuration changes, the Bosch configuration simplification, but co-locating all of those jobs onto one single Docker container and that's what the CFSolo does. Yeah, it's one really fat container but it's much thinner than all of the VMs that you might otherwise see. And that's what CFSolo represents. However, it's not just about the container side, here we're at the OpenStack conference, so let's enter OpenStack and Magnum. So as you saw most of the stuff before, let's just, hey, well, let's get to containers and I could run that actually on a machine that only had Docker demon running and kind of simple. Obviously, it's not gonna get me anywhere into some sort of production scale. So we've been looking mostly at Kubernetes, I mentioned before, that's what our target was and that's what we're trying from a kind of a corporate perspective to raise it up so that Cloud Foundry could be retargetable in that sense and Magnum is one of those areas. So really, how does it work?  So first off, what do we start with? OpenStack, our OpenStack base is SUSE OpenStack Cloud 7, which actually has Magnum as one of the core components. I'm not gonna go too much into that one if you wanna see more about that. I believe there's other talks going on. In fact, I know there's other talks going on this week from the guys who on our OpenStack Cloud side on that. It is based on upstream Newton, in case you're curious, and does include the Kubernetes as a service. The Kubernetes here used in this demonstration is 153 and the Docker was 112. So then enter Magnum. And I say this all in a few slides to make it look easy. It's not quite as easy because I'll get to the quirks in a little bit. But basically we're using a Magnum heat template with some DNS server added onto it. It's important that you choose the appropriate OpenStack flavor and the Docker volume size so that your cluster can adjust as necessary. And this little command is pretty much all we used on top of a stock SOC 7 system. Oh, well there's a couple of other things that preceded that command. One, you wanna grab your SUSE Linux Enterprise or you pick your other one, but something that has a Kubernetes-enabled image uploaded to Glance, so Glance, ImageAd, blah, blah, blah. The LBAS side is not strictly necessary, but if you're gonna do anything with public IP exposure, then you'll need that. And then make the requisite local DNS corrections. And that is then the command which would kick it off from essentially, this is creating that cluster template. So, we've created a template. Now let's create a Kubernetes cluster. So you choose that previously created cluster template and that was in the previous slide, which was whatever name I gave it, I'd already forgotten. And then you give it a number of masternodes and kind of adjust this command as necessary. It's the command line version I'll show you through a demo in a second. So, I make it sounds like it's that easy. Well, it gets to be that easy after you get to, after you rebuild your cluster about 10 times, figuring out what you didn't do correctly along the way. So we did have to do that ourselves. Some of these were kernel options fixes, mostly because in Cloud Foundry, depending on what you're doing, certain things are sensitive to what's available in the kernel, so we had to make sure that we were setting everything up right. We had chosen the wrong flavor for core nodes because we needed a larger root volume or rather we need good volume management and we chose to use something with faster core disk rather than slow volumes. Now this is not a statement on what OpenStack configurations you may need. It happens to do mostly with, we were doing this with kind of desks, so machines sitting under desks, not next connected to the things like fiber channel arrays and all sorts of lovely other stuff. You could use volume management if it had the right level of IOPS in it. We did also stick with device mapper. We were trying to use overlay FS but again the configurations were not available to us in the particular OpenStack setups that we were, the restricted hardware that we were using for the OpenStack setups. Another thing is that in this particular case, Magnum isn't really configuring Flannel correctly for EdCD and it didn't do the master right for cubelets. We had to change some stuff in the Etsy Kubernetes configs to address this. So while it might have worked and you would have said, if you use Magnum and says, I am kind of ready, it wasn't ready for Cloud Foundry, which is itself sort of a large and complex workload wanting to run its own distributed configuration management and other stuff on top. We also required the host path provisioner because Cinder again was not attaching. Again, we're pretty sure this was mostly limited to our hardware. If anyone would like to loan us some more hardware then I'm sure we'd get around all these problems. Kubernetes DNS configuration changes also had to be added for a service network because we needed a service network for the monster service we were about to drop on top of it. And the one other thing is TLS wasn't configured and this was all our fault because we were using self-sign certs and we didn't want to have to deal with all that stuff. So I'm gonna say sprinkle a cube of salt here. That's actually, it's showing it's working but I'm going to jump now to, I did not show where I thought I was going to show. This is a time compressed demo and I'm not mirroring my screen here so I'm gonna look this way, sorry. So basically this is the setting up the cube on OpenStack, you're going through the creation of the cluster template as I mentioned before. This is, the command line was showed in the slide. This is about picking your image flavor, picking a key pair, all the usual stuff. You can actually all do this from the SOC7 interface and it's going to, let me get that out of the way. Jump that out of the way. So we've created the cluster type and it's showing that there it is created. As I said, this is, it's not that complicated as you're going through all this. The link to the YouTube there is there that you can kind of pause and go through it but again, this is the creating of the cluster. That was the second command line that I showed. We picked a couple of nodes and I'm basically compressing, we were trying to do this as a live demo but then realized that that was not gonna happen. So also especially the time it takes to download all the images when you go through building this but we're showing the, that was the cluster creation and we have our Kubernetes that was set up on a three nodes. So okay, three node Kubernetes and they're now ready. And so next we're going to basically go into the DNS as I mentioned. This is just some of those weird configuration items. Gotta have DNS working, you know, it was one of those quirks and especially between the configurations expected between OpenStack itself, Kubernetes and Cloud Foundry. You have to make them all consistent and they all kind of disagree on where that might, the DNS configs might say by default. So here we're just basically setting up, exposing our port so we can set up the cube dash and then we have a tunnel to get us going pretty fast. Ooh, it's going pretty fast. Now let's pause that and back to the slides and let's talk about the Cloud Foundry piece. So Cloud Foundry on top. So I basically compressed what was probably about, it's kind of 20 to 30 minutes of getting, you know, in the system that has to get the images and then it runs everything up to the stable ready state and I took a pause and we're going to say, okay, well, now we need Cloud Foundry. Cloud Foundry is itself quite a large and complex system but aside from going through and learning what some of those other configuration quirks were, the two minutes compressed there does represent a, oh, you know, I've got and set up and I now have a Kubernetes cluster that is ready to take Cloud Foundry without any other confusion or sleight of hand going on. So most of the things were related to service discovery and DNS. There's this assumption for cluster.local being your default discovery domain and but Magnum imposes something else and then who are you going to impose the configuration on? At this point, we're kind of adjusting things by hand in YAML files. I think if you were to harden this, you would make sure to really focus on a better kind of end-to-end configuration control for these things. There was also some Kubernetes namespace assumptions that we had to change and it basically represented more stuff that we needed to make configurable. So going back to here, let's get into that. What is that Cloud Foundry setup? And first we're going to set up the UAA for those, you know, Cloud Foundry. It's kind of, in an automated configuration, this might all look like it's one step but you really have to have your user auth and authentication all set up and making sure that it's talking to the right things from a service discovery perspective first. You have to have UAA knowing that it's talking to the right services and then Cloud Foundry will need to find that as its first piece. So here we are setting now up UAA and as you see the time clicking away at the top, which is why we've compressed this, it does take a little bit to get that all up and it showed about five minutes. Now we're basically just going to, we knew what our internal IP was, now we need to expose that and this is basically the dependency chain that you get through. Again this could be completely automated as it has been before but now we are showing that it's up and it's working, we were able to ping it. So now we have UAA, we can go in and distribute or deploy the rest of Cloud Foundry, create the namespace for it in Kubernetes and then we basically have this configuration file which is all the fissile generated configuration and that was pretty much it. Again this is slightly compressed in time and that it's operating but this is also assuming that you've already downloaded the images and so that, because there's probably 30 gigabytes worth of images across these things. There's a lot of layer sharing if you happen to do it right but it can take a while to download. And basically we're seeing that the readiness probes and liveliness probes are being used properly in the system and it's all then getting set up. Everything from API, Diego, the routing and the other bits are all on there. It takes about again five minutes till they've all come to ready state and that's done. So now everything post deployment's done and we're gonna expose it. This is locally so we've gotta go ahead and get the right IP address. Gonna look at the dashboard and again this is the Kubernetes dashboard that was set up earlier and just running all on Magnum. Now we see everything that's running and done. And so now we're just gonna look inside a container just to see, okay, this is actually a Diego so running and we can see that everything is operating properly. Then the next thing is, well, okay, now we've got, that was kind of it. And again, it's only time compressed. There was no cheating going on. You can run those things straight from those Docker containers. We only had to make some slight changes on the ones that we'd otherwise had published before for some of these Magnum quirks and then you can go ahead and deploy something on this Cloud Foundry. And so let's use it. We're gonna target the system. So on our CF solo setup and okay, we are actually pointing to the right thing. That was what that was, call was doing, login and create our orgs. This is all the usual Cloud Foundry stuff. Nothing too interesting here. We're only more pointing out that we're now pushing both the Docker app and as well as a build pack oriented app. So this is the usual Cloud Foundry stuff and waiting, waiting the usual Cloud Foundry push and everything's running. So that's pretty much it saying that it works. Now back to the slides. So where are we currently? The current working state, Magnum, duh, we saw that. We also have this running on Google Container Engine, MiniCube, HyperCube and Suza Casp. If you might not have heard about that, that's a relatively recent project from Suza Container as a service platform. It's Kubernetes, though instead of, so there's Suza OpenStack Cloud and Magnum running on that. There is Suza Casp, which is a Kubernetes system that can do, for example, pure bare metal Kubernetes. Our intention is basically to be running on any Kubernetes system one five or up. One note that for those of you who may be playing with Cloud Foundry in general, we did have to make some changes. We're using the Groot FS, which is not currently a mainline feature. It's an extra optional feature, but it's the one that allows you to avoid using AUFS in your system. And this is a very important aspect of being able to run on other Kubernetes where you can't touch the kernel because you would have to otherwise install the AUFS kernel mod to allow that. The Groot FS is an effort from the core team to use other things, Overlayer or Butter FS, and Overlay wasn't working for us, but the Butter FS was. Yeah, and the Hypercube, we've only deprecated that effort because it seems that MiniCube seems to be better supported inside the community. So a bit about the current development state. Groot FS, again, to alleviate the AUFS current CF requirement, and service discovery configuration improvements that we had to make inside the system that we are now sort of pushing back right at the FSL and config level. And also that kind of touches on how you're setting up your Kubernetes. We do want to be leveraging more Kubernetes features. So the ones that are not italicized are the ones that the first four are already in use at some level. So this is another advantage from going to the containers and container platforms for running Cloud Foundry on, is that we're able to use things like readiness and liveness probes. Ideally, we'd be able to get rid of the whole use of Moniton and further reduce some of the overweightness that has come into Cloud Foundry over time by leveraging some of these external platform features. Stateful sets, because they're a very important part of Cloud Foundry, there is state involved. The deployments of Kubernetes storage classes. The three things that we're not using that we want to be in the future are the concept of critical pods so that you can be tagging certain things for higher level of importance. Pod affinity, because it can be very important to make sure some of your routing stuff doesn't get confused with some of your CPU bound stuff and just to generally assert that and more of the network security sandboxing. In addition, Helm is something that we're looking at. We've been playing around with charts and have some things deploying via charts, but not the entire system. So a little more about where we go from here. As many of you know, SUSE has been extending its community presence and basically growing contribution in many other open source communities. It's obviously long been and the Linux community is the first enterprise Linux offering and followed up in OpenStack, but it recently joined the Cloud Foundry Foundation Board and just last December and the Cloud Native Computing Foundation just a couple of months ago. And if you're interested in the Kubernetes efforts, as I mentioned, that's in the SUSE CAS product which is already currently in alpha beta, beta now. And basically founding members of other new projects. So this is SUSE branching out to other areas. So I mentioned this slide before and I said, ah, you can catch all of this stuff and see where it is. Well, I highlight Cloud Foundry again because that's the one piece you're not gonna find everything for today. And whereas everything else is full open, you can find it as release stuff. Why is that? For those who weren't aware, the source code assets and team, such as myself, were just recently acquired from HPE's Takato Group. So I'm one month shy, one day shy of two months at SUSE. And while HPE can be great about many things, open sourcing at software is not really one of them. But SUSE is very much an open, open source company and we're now going through that process with a lot of the stuff that we built. So, Takato was this full batteries included platform of everything, mostly closed source. We're basically taking the time now to piece all these things out. So, you know, Kubernetes control plane, Cloud Foundry, service manager, et cetera. We're splitting all these pieces. They will all become open. The first two things actually was that, you know, that FISOL and CFSOLO from the Cloud Foundry bits, but more will be coming in the future. So everything you see for the most part actually is in the FISOL and CFSOLO, but there will be more coming in the very near future and all of it will be in the open. In terms of the next steps for features otherwise, it's hardening the ability to target any Kubernetes deployment. A lot of this is mostly around things like service discovery configuration and other setup, leveraging Helm charts throughout, as well as other extended Kubernetes features that I mentioned before, things like critical pods, pod affinity and such. And again, leveraging more of the new Cloud Foundry efforts as well as contributing old ones that had been developed previously at HPE and ActiveState that just never made their way open source, things like application versioning, applications, single sign-on, and backup and restore functionality that we built over time in my team that just never got open sourced. And the last one is an interesting side project that we had along with this, which is called Furnace. Basically, it swaps out Diego for direct Kubernetes access so that you could be running, you know, why run containers in containers? That's exactly how Diego operates. And when you have an entire container control plane underneath you, it's not necessary. Basically, it's an experiment that we proved it's possible, but right now we'll probably wanna focus more on breaking some of the Boschisms and bringing Cloud Foundry back to be a true component 12 factor app type system and then we'll address some of the other aspects. And with that, I say thank you. Were you curious on that? It's all recorded though, so I should be able to catch that anytime. Any questions? So realize I'm spot on time and somebody is gonna follow, so you can always ask me later. Please step up to the mic if you'd like to ask a question, otherwise I am generally around. One quick question I realized we're holding up some deals. So can you just describe a little bit of the helm aspect of this? Just amplify that for me please. So one thing is that if we can truly bring Cloud Foundry right to that containerized control plane Nirvana, as it were, and be easily to install, then it should be able to install via a helm chart by itself. Now the part that I haven't gotten into while there's this entire service ecosystem that can go along with Cloud Foundry and that can go along with the Cloud Foundry service brokers, as was mentioned in Christian's talk before and some other things. Now, if those are deployed via a helm or how you interact with those is an entire open space and one that we're just currently looking into and haven't made any kind of hard commitments, but we do know that helm does seem to be the current package manager of choice with growing interest inside the Kubernetes ecosystem. So if we're gonna work there, we're gonna work with helm as well. All right, thanks. I'll let the next person come up. So thank you everyone.


Enemy has been slayed that's how we do that's how we start Well, yeah, I used to pull you never all over here Brux, Brux, Brux an enemy has been slayed. Thank you. Get him yet. I'll been slayed Thank you.


Thank you very much, Richard, pleasure to be here. So as Richard intimated already, the world economy is in the midst of a broad-based expansion according to consensus forecasts or the IMF forecast, which is actually very closely consensus. We're seeing 3% real growth in 2017 using market exchange rates as rates. And this implies a half a percent acceleration, which is really quite notable for the world economy compared to 2016. And it also marks, for the first time since the financial crisis, a return to the 20-year trend of world economic growth. So I agree I've been doing this for a long time, looking at the world economy in various contexts. I agree that 2017, 2018 will be good years. And I also agree that there are big risks when you look further out, although my focus is going to be on the real economy rather than the financial issues raised by the stability report. I'm sure others will cover financial issues. So 2017, 2018, good years, why? Four elements, just very quickly, these are well-known. Steady growth across all the large economies, accelerations of economies that have been in trouble, Russia, Brazil, Japan and Italy, less trouble in the past, but very sluggish growth. You're actually seeing decent growth in these large economies. The second element is policies are helpful. Monetary policies remain very stimulatory. Fiscal policy plays a large neutral role. The tax package announced in the U.S. suggests that there will be some fiscal stimulus coming in the United States. So it could be even from the short-term point of view a good thing. The third element is, you know, we've had very slow growth. We've had 10 years, terrible time, really, in the world economy. There's a lot of pent-up demand. And there's also a lot of underutilized capacity. So in half of the 60 largest economies in the world, unemployment is still over 5 percent at the moment. That's a good indication of underutilized capacities. And finally, inflation is very subdued. Oil and commodity prices are still very moderate. And so inflation is under the 2 percent benchmark. That's at the headline level. If you look at the underlying inflation, it's even lower than that. So these are the elements, essentially, of the optimism for the short-term. If you look at imbalances, there's actually relatively few imbalances in the advanced countries. People will challenge me on that. The big exception that I see is Germany's gigantic current accounts surplus. But it seems like the other countries, particularly European countries, have learned to live with that. So actually, when I look at risks, I'm not being politically correct. I actually see relatively little by way of short-term downside risk in the course of the next year, year and a half, when I was running the forecast at the World Bank. I would have been more cautious. I don't see much downside risk. In fact, I see some upside risk. And 2018 could be closer to 3.5 percent than 3 percent, essentially because, from my experience when the world economy gathers momentum like that, there is a self-feeding mechanism. And that's also one of the reasons why when I go into 2019, I think people might be surprised by the, there will be some pickup in inflation. And markets may be underestimating the rising interest rate that will be needed, not necessarily in 2018, but going into 2019. And that could cause some issues. But as I look at the long-term, then I want to talk about the long-term, because for me it's the most important at the moment. There are, so if you look at the long-term, we've had a slowdown, big slowdown in the labor force across the world. We also have had relatively low investment in recent years. And productivity growth has been relatively slow. So it would be imprudent to assume that you're going to get more than about 3 percent growth over the next 20 years as we did over the last 20 years. But I want to make two qualifications on the optimistic side. One is that we don't really understand what drives productivity. Total factor productivity is measured by economists as a residual from a regression, which essentially means we don't know what is driving it. And there could be a lot of innovations coming down the pike. There's a lot of indications that there will be. So we may be seeing accelerated productivity. But the other factor, which is perhaps just as important, is that regardless of what's happening at the technology frontier, developing countries are so far behind the technology frontier. And they now account for about 40 percent of world GDP at market exchange rate. And they're growing about two and a half times faster than advanced countries. Developing countries can do even better than what they have been doing in recent years. And that, together with the possibility of a productivity acceleration, could make us quite optimistic about the medium term. A lot depends, and in fact, it is very important what the policies that are pursued in developing countries will be with regard to whether they're going to fulfill that potential. And that is where I go now in the long term and tell you about my pessimism, why I'm very worried about the policy picture. And I could mention two or three things, but I'm going to focus on one since we have very short time. And the issue I focus on is protectionism. I don't mean to pick on the United States. I live in the United States. I admire the United States. The United States is the most open, large economy. And protectionism today is a much more prevalent feature outside the United States than in the United States. However, the fact that the United States is turning inward is profoundly significant. Furthermore, I see U.S. protectionism as not just a temporary Trumpian aberration, but the result of the U.S. economy's failure to adjust to stagnant wages and rising inequality caused by technology and globalization. And Kamal to my left here, and I wrote about this risk long before Mr. Trump came on the scene like several years before. And unfortunately, current U.S. policies I'm finishing, current U.S. policies such as tax cuts and reductions in health coverage are not only failing to deal with the underlying problem, but they're making it worse. The U.S. is bound to be profoundly destabilizing both at home and abroad, and it's going to give a very bad example to the developing countries that we hope would be the future of our long-term prosperity. And if it persists, if we don't have some unexpected event, and of course there could be, given what's happening in the U.S. at the moment, if it persists, then we may soon be looking at the 3% global growth rate of 2017 with some nostalgia.


If you are planning for an L1 visa interview with your dependent, then this video is exactly what you need. Today's video is going to be a real visa interview experience and I have with me two people, Anurj and Rohani, the husband wife duo, who are going to share their L1 and L2 visa experience. And this video is going to talk about the entire process, how they planned their entire visa journey, what were the questions that were asked to them and a little bit about their life in the US. So keep on watching. Hi guys, my name is Shachi and I'm a travel and visa coach. On this channel, you will find lots of useful videos on the US visa process. There is an entire playlist for L1 visas, so make sure that you subscribe, press the bell icon and check out these videos. Before we start, I would also like to tell you that we have a free PDF download and this PDF is a question bank of all the questions that have been asked over the last couple of months for L1 visas. A lot of people have used it, found it extremely useful, so do grab a copy of it. The link for this PDF is in the description box below. Coming back to today's video. So today's video is going to be a real visa experience video and I have with me Anurj and Rohani. Anurj went to US on a L1A visa and his wife Rohani joined him on an L2. And in this video, they are sharing their entire visa journey. So Anurj is going to tell us about the entire process, how exactly it started, how much time it took for the petition to get approved, for him to get the visa slurred. Then he talks about his visa experience, how he prepared for the same, what were the questions asked and he's also sharing with us some extra tips, tricks and as a bonus also telling us about life in the US and what the path ahead looks like. In addition to all of this, his wife Rohani is going to join us and talk about L2 visa experience. I feel that this is a part of the visa experience, which is often overlooked, but if you are applying as an L2, you too need to prepare to a certain extent and keep your profile and how exactly you're going to present that to the visa officer in mind. So all of this is being covered in this visa experience. Let's jump right into it. So hi guys, today I have with me Anurj and his wife will join us shortly. So they are in New York currently on L1 and L2 visa and he's here to share his entire experience right from preparation to what actually happened in the interview and also have some special guidelines and tips for all of you are going to be appearing for the interview soon. So Anurj, what's up, how are you? Hey Shashi, hi, nice to see you. How's New York? Yeah, long time. New York is good, we're just dealing with a bit of cold. The winters are really long and harsh. Extended winters. Yeah, for special people in Bangalore, I'm sure you would not know what winters are. I know. Yeah, like spoils and good weather. So starting with your background, so you basically worked in India for some years and then moved on an inter-company transfer right for the financial institution. So how was the entire process? Like how long did you know, right from the fact that you came to know that there is this opportunity available to finally getting to the visa interview itself? So how much time and effort did this process take? So let's start with that, yeah. So to start with, I applied for L1 visa. So within L1, there are two categories, L1A and L2B. So L1A is for managerial experience. If you had a managerial experience in the company, that is transferring you abroad and then you are going to a managerial role in the foreign country also. Then that's when you apply for L1A visa. So mine was L1A and the entire process, I think it took around five to six months starting from when I was being communicated by the lawyers that the process will start and I was assigned a lawyer till the time I actually flew. So the process, so in L1A mostly the company assigns a lawyer which is supposed to take care of the documentation and process and file the petition with the USCIS. So that started and preparing the petition, I would say that takes a long time because there are a number of questions which are being asked about your job description. What do you do about your personal information, etc. So that takes time. And then after that is done, you file for one DS160 and then you pay the fees, you take an appointment. And between the petition filing and the DS160 Getting the appointment. Getting the appointment. Most likely the petition will get approved because the lawyer's file for premium processing does not take that much time. So then you have to really prepare for the interview because that is when you don't know what they are going to ask. So this process took approximately 5-6 months. Getting till the visa interview. So getting till the visa interview and getting the passport back. So from the starting till that time it took 16th and maybe it's taking slightly more during these times, maybe it was shorter or the things will improve and the time will reduce actually when things become getting longer. So coming to the interview, the process is slightly different for blanket applications and for cases like you. So how much preparation was done from the company's side and how much effort did you actually put into your research and figure out that okay, this is how I have to be ready for it. So companies normally they have very set documentation or the questions they ask for. And I don't know but lawyers do not actually help you with the interview. They just tell you what is the visa type and they ask for the documents. Then you actually have to go online and talk to people who have the similar kind of experiences to understand what are the questions which would be asked. So for example in L1A, the lawyers never mentioned that they would be probing around your managerial experience. So in the interview they want to understand if you're actually manager or if you're just an individual contributor, specialist who will do that kind of a job. So the lawyers will not or like in my case the lawyers did not mention that. Okay, so the owners wasn't you to figure out? The owners wasn't me to understand what kind of questions they might ask, what kind of things they want to uncover. Okay, so you prepared, you had like an idea of what to do for the interview and you also applied with your wife. So there's a lot of confusion which people face which I get a lot of questions that should be like apply for L1, get our visa and then the dependent should go or both go together. Like in my opinion, there's no difference. I think L1 and L2, they go together. It's like a much more sorted process but you both applied together, right? Like you went in like one single interview. So what is your opinion on this? That said, I think applying together is definitely better because if L1 gets approved, most likely L2 will also get approved. And it also reduces the time because when you file for L2, you again have to do very similar documentation, provide your wife's documentation again. So filing together definitely reduces the time. And I don't know what's the impact on the decision but most likely it will only benefit. Right, there's no harm in applying together. So your interview was in Delhi, right? Delhi Consulate? Mine was in Delhi. It was an individual process, it was in Delhi. Okay, so what was the actual interview like, right? What did you observe and what questions were asked to you? So they asked a lot about what do I do? What will I be doing? And in most of the answers, I mentioned that I manage or I get things done or I manage these set of people who do this and that and etc. So a few questions were about what do I do and what I'll be doing. Okay. Then there were questions about my experience, how long have been with the company? Why do you think is the right role for you? So they also want to understand that it is a critical position about it. If it's not critical, then they may say that there's no need for it. There's no need for you, right. So they also try to understand that critical is the position. So I would say that some thought also went in that direction. And then mostly about my wife. So my wife was also there for the interview and they asked her a few questions about actually I have her here with me. So why does she answer that? So what was after you? As you can see, I mean, I didn't participate in any organization for L1. But definitely during the interview, they wanted to know if I planned to work in the US. And I did say that, yeah, I did plan to work in the US. I would apply for a work authorization after I got there. They asked me what I was doing that time in India where I was working and the move and everything. And I think finally they ended by asking us how many years we'd been married. And like it become quite casual, I think to that point.  And how many people came to your wedding? And that was it. I think part of it was I really constantly answered that it was 380 and he was like, okay, so you basically mentioned that you're working in India and you plan to continue to work in the US. Because this is also a point that scares a lot of people, right? Though on L2, I mean, it's easier to get work authorization. And that's the whole point of this. But still people are scared that if we show that even the dependent will work, it might show a lesser intent to come back. Did you ever have any such thoughts? So I would say they are different school of thoughts around this. Because people who spoke with some said that don't mention a friend that I want to go there and work. Right now you want to apply for the visa so that there's a possibility of work in the future. You'll go figure out what you want. Yes, so right now we are not exactly how we want to go about it. But once we get it, then there are options for us. So then we can think about if we want to work in the future. Yeah, I think even for the both of us, our whole perspective is we are not going to lie. And I would strongly suggest do not lie on your visa application. The way you describe things is obviously very, very important. But I think if you're lying or manipulating some facts, it sort of comes across. And so we wanted to upfront say, yes, I plan to work. And it might not be the best strategy or the best even approach for someone. People might want to take some time off and so say what it is like. Right. Okay. So really depends on the case to case and individual and how comfortable you feel essentially there like what you're saying. Okay, fine. Thanks Rohani. So coming back to your interview, the one thing which I want to understand like the two questions that you mentioned in the beginning, that's essentially the crux of it. What are you doing in India and what will you do in US and why are you required there. And in some cases recently, they've even started asking what will happen if you don't go there. Did you like focus on the expertise that you have built in this company over the years and say that because of this, I would be the best person for this job or did you like pinpoint to some specific task or role in the US that was waiting. Which it totally depends on the role that you're going for. So in my case, what I was doing in India was slightly different than what I would be doing in the US in particular as a function. But obviously the core skills still remain the same. So I tried to link the skills that I acquired in India plus my people leadership experience and how could it help the role in the US. But if you think about it, the question you asked, right? What will happen if you don't go there versus how critical are you for the role? These are similar questions in themselves. So you have to justify, how does the skills required for the role that you're going for is very closely tied up with the skills that you have. And I don't know if they further want to ask, do they don't have any such people in the US for that. So that would be something which is- They do ask. They do. Yes. Why not someone in the US office, right? So these are the type of questions that we are seeing recently, like off late. A, what is your expertise, what's your specialization? Buy you and what will happen if you don't go there. So very closely, but different questions. So I think like you mentioned, showing your expertise, the special skills plus depending on which visa category, like your managerial experience in your case was important for someone with L1B. Maybe the technical expertise that might have more value. But one has to be really clear about these two, three points essentially. They have to think about very carefully how do you word your answer and what kind of words you use, what kind of job description you're describing. One has to be really careful about all these.  Asking for what kind of stuff you'll do. So most likely you'll be the answer, even if you're not prepared. But the reason that you should be prepared is it just helps you with the answer. It just makes sure that you are calm and composed by answering the question. You don't actually screw up. You don't say something that you don't, which you never. It's basically an interaction. So it should be like a calm, friendly interaction for which you have to know that, okay, this is what I need to say in this one. So make sure that you don't, you just use the right words. That's the advice I give. Okay, great. And one last thing, what is the path ahead? Like a lot of people are also really interested to know that, okay, once you're there on L1, right? What for somebody who wants to sort of think of US as an option in the long term. So how does that path look like and how easy or difficult is that? So for L1 A visa, actually it's much easier compared to say L1 B. And it also depends from company to company. Some companies, the moment you come after six months or one year, they file for the green card. And if for example, right now, if L1 A files for green card, that's AB1 category. And the green card duration or the processing time is under two years. Whereas L1 B, it will be somewhere around five years. So there's a lot of difference between the green card processing time for L1 A, L1 B. But definitely that's a good option if you still want to see yourself in the US for a long time. Because for example, for H1, I don't know, I don't know people who have been in the US. So L1 A, L1 B visas are definitely much better in that respect. Okay, great. All right. Okay, Anurj, thank you so much. I'm wishing you all the best for your stay in New York. Thank you, Shachi. Hope to see you soon. Bye. Yes. So I hope you found this entire visa experience useful. If you have any more questions for Anurj or for me, leave them in the comment section below. You can also DM me on Instagram. My Instagram handle is at shachi.man. If you do want to prepare with me, feel free to book a one-to-one session. The link for this one-to-one session is in the description box below. This one-to-one session will help you with all aspects of your visa interview. Right from reviewing your DS160 form, answer structuring based on your profile, and of course, giving you some practice through some mock sessions. So all of this is covered. Check the link in the description box for the same. And that's all for this video. Thank you so much for watching. Don't forget to get your free PDF. And there are a couple more useful videos planned for the L1 visas. So make sure that you subscribe and hit the bell icon. I'll see you in the next one, signing off for now. Bye.