 Thanks guys. This is a presentation that my colleague Matt Pryor gave at a great science conference last week. I think it's a little bit longer than the lightning talk, so I'm going to blister through the first bit. I think it's the novelty or the interesting pieces to the audience here is probably towards the end, so we're going to crack on and go and have a look at some of the pieces at the end. So what we're talking about here is another cloud portal. This one is more focused on multi-node platforms or managing compute clusters. So the driving force behind it, it was originally developed in order to service the kind of dynamic HPC environments that at Stack HPC we have been delivering more and more and sometimes at increasingly large scale systems running in the in the top 500 today are running these kinds of platforms. And really it serves to this idea about dynamic HPC. So we have this technology stack where we're bringing tools like OpenStack into service as an infrastructure layer beneath Slurm and Kubernetes and other kinds of scientifically oriented compute platforms in order to simplify the way that users are accessing science workflows. So the project was originally developed by a UK meteorological weather cloud called Jasmine and Stack HPC's team have picked it up and adopted it and developed it a little bit further for a science federation across the UK called Iris. The main focus of it is to provide self service for users including of multi-node compute environments without imposing on those users the obligations of security and maintenance and learning to become effective sysathnins because I think that would serve nobody in a very, very reliable way. So what we provide it's more as the line at the bottom says here it's got more than infrastructure as a service but it's also more flexible the self service components more dynamic than a platform as a service is typically provided. I will skip through some of these pieces and I guess that there are three use cases the first one is actually very similar to what Exosphere has been providing it was very nicely demonstrated just now so that is this idea about being able to get research computing environments easily deployed in many cases a sort of a single node work station environment often referred to in our circles as moving into that transition stage from a scientist laptop and coding on the laptop into a managed cloud infrastructure often referred to as the bigger laptop model. So the idea there is that a user would log into the cloud portal simplified sort of take on horizon but focused on this curated set of applications and I think I will skip through this bit because we have seen some of this but some of the key features here one is that we operate particularly well in environments which are short on external public IPv4 so there is no external IP everything is tunneled through an application proxy which is managed through the portal. The users authenticate to the system using generally using OpenID Connect or using the Keystone services themselves. In the OIDC case we use the same module as Keystone so it usually requires another configuration source within the ID provider but otherwise it is a federated authenticated model where we don't handle the credentials for the users they go to the IPP instead. Another thing here that writing is really tiny I doubt you'll be able to see it but in this case we're using Designate to manage a sub-domain and we provide this auto-generated sort of encoded application proxy endpoints for users to access these are authenticated through the OpenID Connect session so there is no further authentication once the user is authenticated once they can access very much the same kind of experience as we had with Accessphere just now so a Guacamole or a desktop or a web shell. I'll try and skip over this bit a little bit quicker so the one of the key pieces that is interesting here is the use of this Zenith application proxy which is an open source project that we have been developing here at StackHPC and is available on GitHub. That is installed by invoking an Ansible Playbook as part of the cloud init cloud config for the service when they boot. Things get a little bit more developed when we start to look at deploying these multi-node platforms. The main example of this is a slurm cusp cluster but there could be plenty of other options for deploying multi-node compute. We fill in a survey or question-air form in which the key parameters for the cluster are entered. This is all done through Ansible Playbooks on GitHub so behind this there is an AWX or Ansible Tower instance which checks out a Playbook for deploying the cluster and there's metadata within the Playbook for the different parameters that are required for user input. So we enter those things the slurm cusp cluster gets deployed, comes to life and I think we then get these key pieces on the right hand side here are the services that are exposed through the application proxy. So without requiring any floating IPs on the system we get to access Prometheus dashboards or open-on-demand interfaces which have been embedded within this deployment and exposed through the application proxy whereas sort of named ports that can be accessed through the user's session to azimuth. I think probably that's enough to show about the way that the multi-node slurm clusters are deployed. We can also see as you see here some sort of basic telemetry from node exporter. We also have a slurm data collector or dashboard and so that will actually expose data about jobs running within this sort of self-serviced slurm cluster platform. I'm going to skip through some of these pieces in the interests of time because what I'd really like to focus on is the zenith proxy which I think is the bit that you guys would like to see. So the third major area of complete compute platforms that azimuth supports is deploying a Kubernetes environment and deploying applications within that. Kubernetes is deployed using cluster API and so we get a well-supported upstream maintained open stack integration with Kubernetes through cluster API. So we key in the parameters in the form as we did before and we can also add things like autoscaling so that a job will ramp up and down as required. This is also available for the slurm cluster as well so slurm has some support for autoscaling. It will increase the number of worker nodes as the queue gets longer. For the Kubernetes side so one of the useful pieces that we can add is I think it's the autoscaling first or I forget. So one of the useful pieces we can add is how to install applications in a friendly way so we have this thing called the integrations with kubabs. Another useful piece here is for direct access to your kube config. It's easily exposed through the portal so that you can actually access the Kubernetes cluster from the command line too. I think the other pieces here so again the Kubernetes clusters have integrations back through the application proxy so without creating any external IPs or any floating IPs for the system we can access through the portal a set of preconfigured services including the applications the third one down which is the kubabs. So as usual we get some access to monitoring dashboards and telemetry performance for the system and then we get access to a catalog of applications which can be curated by the operators of the cloud. I think there's a little demo coming up here of some of the autoscaling. Get access to things like Jupyter hubs, Jupyter hub and DASC environments as well through these preconfigured kubabs. The point in red here everything is authenticated once when we log into the portal and then because we retain the same session throughout there is no further authentication from end to end on the system. So quick Jupyter notebook and then I can't show you the demo I'm afraid but we can share it there's a nice demo of using DASC for autoscaling who doesn't like a bit of autoscaling in a demo I can't share it for you today though. So I'm not sure I'm doing for time but it does look like the clock is progressing so I better focus on the final piece which was this Zenith proxy and this is really the piece that has been driven through a lot of requirements that users have had on infrastructures that we've been working with. So for example a shortage of IPv4 or an unwillingness to use large amounts of IPv4 floating IPs for large-scale compute clusters for example. A little bit hard to read the diagram here but the way that it works is that on each of the compute nodes they are configured to dial out an SSH connection so we create a reverse tunnel back into the Zenith application proxy running in a service tendency. So there is no exposure of inbound connections it is all managed through an outbound connection which has some reverse forwarding of ports. I think as it says on the line below we'll have a blog post coming on how Zenith does what it does in greater detail soon. So that's what we've been up to I think that's pretty much it. There's a lot of of course there's lots of other things that we may want to work on but I think time is going to have to cut that short so I think I will stop there. Thank you very much.