 OK, I'm Troy Topnik. I'm a senior product manager at SUSE, and I'm responsible for cloud application platform. We just had some news here. They're releasing version 1.1 of our Cloud Foundry distribution. And Stratos UI is a very important part of that distribution, and it's an important part that has become an upstream incubated project. We're quite proud of it. I'm not the ideal person to be presenting this, because I'm not actually the dev lead, who I want to give total credit to, a guy by the name of Neil McDougal, who's head of our wonderful Stratos UI team in Bristol, UK. And I just want to make sure that they get all the credit for this. He prepared these slides for me to walk us all through the work, the very hard work they've done, and the excellent work they've done on making a great open source UI for the Cloud Foundry community. And to that end, he was the one who presented at Bazel the unveiling of Stratos UI and the ask of the community that could it be accepted for incubation. So he gave a demo in Bazel, and we submitted it for incubation in December of last year. It was quickly accepted and moved from the SUSE GitHub org into the Cloud Foundry extensions GitHub org. And now we just call it Stratos. That's the project name. And so for those of you who haven't seen it before, we'll leave a little bit of a time for a demo. But I think a lot of people saw it, the demo I made yesterday in the keynote. So we'll try and leave some room for questions. And again, I'm not Neil McDougal, so I won't be able to answer the most technical questions about this. But I'll do my best, and we can defer some of the other ones to the Stratos channel in the Cloud Foundry Slack. So I'm going to talk a little bit about what Stratos is, what it's meant to do, some of the key features in it, how to get it running. And it's actually very easy to do. So we'll talk about the ways you can do that. The team's been very hard at work moving to version 2.0, which is based on Angular 2.0. And we'll give you an idea where we're going with it in the near term. Look at the architecture. If it looks like there's going to be time, we'll do a bit more of a demo. We can do it a little bit interactively. We can maybe look at things that people here have a particular interest in. So I'm going to actually read this one. Stratos provides an easy-to-use web-based UI that allows developers and administrators to manage their applications and Cloud Foundry deployments. Interesting use of the bracket S here. And it's something that some users of Stratos don't notice if they're CF pushing it to Cloud Foundry, because you can actually set it up with multiple endpoints. That's one of the key design considerations at the root of Stratos that we're glad we made. So it's open source, CF extensions project, very actively developed now. And we're getting more contributors all the time to this project. We have two audiences for this UI, both the developer and the CF admin. Obviously, there's going to be a lot more developers on any given Cloud Foundry system, but the admin is a very important person who also needs tools and to get the parts of the API exposed that he or she can use. We've made it very easy to deploy and supports, as we said, multiple endpoints. Uses UAA for authentication. Right now, it actually fronts that with a Stratos interface, but we're going to make a change there. Endpoint management. Not only Cloud Foundry API endpoints, but other kinds of endpoints as well. We have an application view, both in a grid and a list. The ability to create applications, deploy applications right from the interface. And what we call the Cloud Foundry view, which is an administrative view of a particular foundry and some of the switches that are available to administrators, people who log in with administrative credentials. This is where you go to find it. As I mentioned, the Cloud Foundry incubator and the stuff that I will be talking about today is in a branch called V2 Master, the newest version of it. And you can check it out and push it, but bear in mind, Angular has this funny memory leak, so you might need a lot of memory on CF to actually complete that push. But it can also be deployed, as we do it in the Cloud Application Platform, via Kubernetes chart. So there's that way. That's for deploying natively to Kubernetes. You can run it as a single Docker container. You can build it right from the repo and then run it in Docker. Or you can deploy the Bosch release. So if you're using a Bosch-based Cloud Foundry distribution, which most people will be, you can use the Bosch release we made. So as I mentioned, it was accepted to CF extensions. We've got an open Slack channel now for Stratos. And that's growing. I see people joining it more and more today. After yesterday's demo, a couple of people joined, a couple more today. Some discussions going on there. Version 1.0 was released along with 1.0 of Cloud Application Platform. These versions are not tied together in any way. This is a separate project, and so its version is going to increment as it needs to. We felt it was smart to increment to 2.0 because it was moving to AngularJS from Angular1 to Angular2. And yeah, this is a key thing about 2.0. The word I was searching for in yesterday's keynote demo, which I could not remember, was Google's material design. And there's a set of design principles which were adopted, changed where things were positioned on the page, changed how they were grouped. There's some detail on that a little bit later. UI improvements. Services support got bumped up a level so that people knew could more easily discover that and find where to manage their services. And we added the ability to connect to a metrics backend to reflect a history of the performance of that application. So I'm not a huge fan of AngularJS, but there's some history here that we started on AngularJS a long time ago. Some of this code originated from the Staccato 4 code base at HPE. And there was a lot of concern, even at that time, that there was going to be an end of life for Angular1. And so we made it a priority as soon as we were out the door with our status UI that we wanted to get on Angular2 as quickly as possible because then we would have a clearer migration path to subsequent versions of Angular, which are improving with each release. So we wanted to have something that would have legs going forward, and that also more people would care about and want to help us develop on. In the midst of that, we got some nice performance improvements of the interface itself, and it allowed us to do some other refactoring. The team started using TypeScript and Observables, which allowed us to do some things in a more elegant way than we could with the previous version of the code. So there was a lot of benefits for us to making that move now before we start getting a lot more people working on the code base. One thing that is the most visually noticeable thing is the adoption of material design. It makes it a more easily recognizable interface in its default. This is all skinnable. You can actually make it look however you like. You can brand it, but the base that we work from is nice and simple, extremely clean. And it's a lot of projects using it. It's not just Google. You might recognize it more from using Google interfaces, but there's a lot of projects that are adopting this as well. There are some good libraries for it in Angular, and we're starting to use those as well. So what that looks like is this. So the change looks like this, because this is the old one. This was the themeing for the open source version as a V1. And here it is now. The groupings are a little better. We've got a little bit more visual indication of the state of certain things. And yeah, easier to locate the things that are important grouped logically as per the design manifesto. In the instances view, we've moved some things into separate tabs that previously weren't. We've got these wonderful little color cues in each of those panels that give us a little bit of information on the status of that card. And breadcrumbs were huge. I know this was very important to Neil, so that it was clear where you were in the interface and how you could navigate. And it keeps the context of how you got there, because there is more than one way into some parts of the UI. We wanted to make sure that when you clicked back, you knew where you came from. And it was just a nicety that we could do with Angular now by keeping track of that information. So one of the new tabs that I showed in the demo was the GitHub tab. So with 1.0, we had the ability to deploy an application directly from GitHub. It searches the project and actually used the GitHub API to pull in some information about the project that you were deploying, so you could see that right in the interface. Now we can track that after the application has been deployed so that we can take further action. And what I talked about in the demo earlier was that you can redeploy when changes happen. Something that was important to some external contributors we had from Orange was that we wanted services to be more visible, so something that was really discoverable only through the applications view previously is now a first class citizen of the left nav. This doesn't show very much when we're looking at the limited set that we've got here on the screen, but this fills up very rapidly when you're connecting it to BlueMix or one of these other systems with lots and lots and lots of services there. And what is not quite there yet is the ability in the interface, as you had in version 1, to actually launch and bind services right from the interface. It's coming very soon, and we're getting some help with that from external contributors as well. Metrics is new. I mean, it's not new, but it's new to the interface. Neil developed this method of attaching a Prometheus database as an endpoint to Stratos that can capture the metrics that are taken from the firehose and expose them in this view. So we get over time the detail of the application. So mostly done, we want to get feature parity with version 1. It's very, very close. There is only a few things. I've only actually been playing with this version for about a week now, and so sometimes in the demo, I was looking for a feature that I was expecting to be there. There was only a couple that were missing, and I don't anticipate it'll be very long before we have all that we had in v1 plus the new things. And it's the v2 master branch to look at the Angular 2 code. So what's in the near term? Finish that work, the migration to Angular 2 so that we've got to feature parity. We've got some detail in our roadmap on what we want to show in the service catalog, the service instances, keys, JSON schema support for binding and creating instances, some more metrics work. And the important one here, if you saw my login screen from yesterday, it actually, it's a Stratos UI login. We had a very astute request to actually just use the UAA login page so that whatever authentication mechanisms are enabled with your particular UAA are then exposed in that page. So the prime one being multi-factor authentication. UAA can handle that if you've set up the back end correctly, so we want to make sure that people with that setup can use that, so supporting UAA login directly. And we can deploy from GitHub and public Git URLs, arbitrary GitHub, Git URLs, but we haven't been able to deploy from private Git repos, so we're going to add that ability as well. So the high-level architecture, and here I'm going to get really close to my screen because this is probably important to some of you who work on UIs and have worked with the Cloud Foundry API. We decided initially when we started working with this that we didn't want to build a UI, and this is going back to the history of the interface, that the smart way to build it and the most portable way to build it was to focus only on the UI. We would not require the interface to have any other special connection to the CC database, and that was our self-imposed restriction. By doing that, we've got something that can be used with any Cloud Foundry distribution, certified or even otherwise, as long as the API is compatible, as long as there's full API compatibility. So we've got a single-page web application in Angular, and this very important API server back-end, which acts as a proxy to the different components and the different APIs that it has to talk to. And then a database that stores some state information for the application. And that, by default, when you just see if push it is going to put it in an SQLite database, but you can hook it up alternatively to MySQL or PostgreSQL. I can't remember which one the Helm chart uses by default. So the API server actually provides its own REST API for managing the endpoints. And the endpoint store, I'll just read it to you here, one or more endpoints can handle one or more endpoints, and it manages the tokens for those endpoints. So when you log in through UAA, you are presented with an interface that shows you all of the endpoints that you're connected to. The administrator will configure which endpoints are available. You then log into the endpoints with your own credentials. So in those endpoints, you will see whatever permissions you've been granted in that particular endpoint. This is what we saw yesterday. Some things to call out when you want to deploy an application, you'll see these two buttons. We need your feedback as to whether this button is a good idea. There are two. I can't guess which one to use as a new user. This one adds an application. This is a totally legitimate thing to do when you're designing based on the API. This is the Cloud Foundry API call that adds an application. Does anyone know what adding an application does? It doesn't deploy it. It actually just puts a little placeholder in the foundry for the application to go. So we can, it's basically going to be empty. Give it a name. Give it, it does give it a route. So that's all it does. In order of importance of things you would do as a developer, this one right next to it is much more important. So I've had a lot of people go, well, I tried to deploy an application. I can't, you know, it just created this empty thing. Well, that's actually, this is actually the one you want. So we need to make some decisions about how exactly we want to make that differentiated a little mouseover might help. This is basically what I showed yesterday. And I'll show it maybe with the same, maybe a new one called Dizzy Lizard. Yeah, so this is just a Node.js application. And we, what this doesn't have, which was going to come really soon is something from the older interface. If we want to deploy an application, we can actually deploy it from a local file system. So that'll come to this interface as well. This is using WebSockets to get the logging information, the stream of the staging process. And while this is happening here, it is also happening here. So even before we have anything else meaningful in that interface, we can monitor it here. And of course, as an administrator, you will see some of this information, you can see some of this information amongst the many, many things going by in the fire hose. I think if we limited it to just the apps, we might actually see some of those staging things happening at a high level. Seems to be done already. So, oh, which one was it? This one. The instances, another nice little touch that was added in this version is the ability to scale up and down with these little buttons. And this is a really fun little app that we made for Suzakan, where you get to basically do Flappy Bird. Oh well, and I'm really, really bad at that game, so we'll skip right out of that. The new GitHub tab with some of that information. Metrics via this metrics endpoint. If we wanted to take a look at more at what this was tracking, we can go look at the Prometheus interface itself and get a completely random graph on something that is just basically a straight line. But this is the back end that is gonna provide us with the ability to track the metrics that we care about in Cloud Foundry, both for applications and eventually, as we build it out, more for the Cloud Foundry administrator. As I mentioned before, the admin view should be different. I think I noticed a couple of interesting bugs that we gotta maybe work on, that a regular user should have a very limited view of what they can do with a particular endpoint. I obviously can't make any administrative changes to Bluemix, and I probably shouldn't be able to see the firehose with just a demo account, so. I can't, and nothing actually is exposed that shouldn't be, but typically in the interface we hide the things that an unprivileged user shouldn't be able to modify. That's basically all I had, but I'd love to open it up for questions if anyone has some questions in the remaining time. Oh, sure, thanks very much. Yes. Thanks for the presentation. Can we set up alerts for the metrics? No, but that's a great idea. So if you, a part of the thing, this is a segue. I remember I do have two more slides. We do want people to get involved in this, and we'd love to encourage more contribution. And the way you would ask for that is to go to the GitHub repo and add a feature request in GitHub issues. And that's the way we're driving the project now, all in the open. And so we're getting a lot of great ideas coming in just from talking to people here at the conference, and so the ability to do that would be a great idea. I was wondering if you could talk a little bit about your vision for your service catalog, kind of how you see that playing out. Oh, is Guillaume here? So the service catalog is driven just, it's basically exposing the marketplace view that you would get with the CF CLI. So I mean, this presentation's about Stratus. I have lots of opinions on what a marketplace should evolve into for Suzy Cloud Foundry and for Suzy Cloud Application Platform. But basically the goal is for the near term to expose all of the parts of the CF API that are relevant to a Cloud Foundry administrator. So there are some interesting proposals on actually hooking this up to, for us it's very interesting to maybe put an end point on there for Helm repositories so that you can actually deploy things to Helm and actually connect it in a backend to Kubernetes. But for the Cloud Foundry marketplace view, the service catalog, we're just following the API there and exposing all the features that we can. So the administrator will eventually be able to add things to the service catalog and perhaps configure service brokers from that part of the view as well. Ken, you show a little bit more about what's visible from an administrator's perspective in terms of trying to help out people who need support. Sorry, say that again. Oh, just the administrator's view of through stratos of everything that's happening in a Foundry. Okay, so, and I know there's some things, these are some of the things that are not at V1 parity. So we can see the organization view and we can see what's been deployed to that organization, how many spaces. Now, ideally we would want to be able to add spaces, which we can, and we can even go back, we can go back one and add an org. So that's something, that is actually something that a regular user might have the ability to do. For example, add spaces to an org if they've been given that permission and that permission would be exposed here in the users. We can tell if somebody's a manager of the dev, of whatever space they're in, or a manager of an org and some of the ability for users to do things within their or space in their org is managed by feature flags. Now, we made a deliberate choice not to make these toggleable in the UI because some of them are things that can really change the behavior of Cloud Foundry. So we thought it's like, for example, well, exactly that one, user org creation, you could go, oh, what's that toggle? If you make that too easy, people might do that without fully understanding that you're giving the end users the power to create their own organizations, which you might want to do, but having to go in and do that from the CLI was advisable as a first step. So we might make these toggleable, we'll have to discuss with people if that's a good idea, but for now, that's what we've done. We, in this version, can see which build packs are available on the system. We don't have the ability to reorder them at the moment or to add build packs or replace them. These are, again, things that you have to go back to the CLI to do and might be best kept there. So administrators who are looking after Cloud Foundry system probably are gonna be familiar with these commands to move build packs, to add new build packs, and they're probably not operations that are gonna happen very often. So we've sort of haven't totally kept them out of consideration, but there are certainly lower priority. The stacks, same sort of thing, and adding a new stack is gonna be a complex operation. And changing a security group, I think there's perhaps a better case for making an interface for this for changing security groups, because at the CLI, you're actually operating with either Yamal or JSON, and you have to go look up the docs and see what you have to do to enable a particular route to a new service that you've added or there needs to be some new special rule. So yeah, we're gonna have to, as we go, make design decisions about how much we wanna enable the administrator through this interface versus just punting them to the command line to actually make changes and making this more of a viewing mechanism. Did that answer the question or did you have more thoughts about the metric side for diagnosing things? Okay, one of my favorite things in the Firehose view in the V1 version, which is gonna come soon enough, was the ability in the Firehose to filter based on substring. So this can get to be a lot of information, but you see something go by, you can quickly isolate those using a substring match or use a regex. So we're gonna see that back in as well, as well as the checkbox filters. As an administrator, can I manage multiple foundations together? Like for example, if I have an active active in my environment, two foundations, then I want to add the same set of orcs in both. Can I do them together or do I have to individually go and add them to each of them points? Oh, so you've got multiple foundries and you want to recreate the same structure within each of those foundries. There's no way in the UI to do that. Obviously, in the endpoints view that I showed, I only have administrative access to one of these, but if I did have admin access, I would see the admin tools for each. And because of the breadcrumbs, you'd always know which foundation you were on, I think, so that would be clear. In terms of automatically creating that structure within each foundation, you could use our new backup and restore CLI tool, which actually can back up an entire foundation and move it to a new one just using the API. If you've got administrative credentials, you can actually back up even the applications and put them to a new foundation. Okay, all right, thank you. I have a follow-up question to that. So you mentioned backup and restore. Are you using BBR to do that? Yes, we're using exclusively the API, and this is not to be confused with Bosch backup and restore, which does things behind the scenes. This is a backup and restore strategy that goes in the other side and just exercises the API. We're firm believers in operating CF that way via the APIs that are exposed. So. Thank you. And an idea came to me this morning that a couple of people agreed with on the Slack channel was the idea of what would be really nice here is if each of these foundries was visually identified with a identicon or something, or a user configurable or an admin configurable icon so that they instantly know when you're looking at the application's aggregated view, this one is on, for example, how do I tell which Dizzy Lizard is where without clicking through at the moment? This one's on IBM Cloud versus this one's on the one that I just deployed. So little visual hints as to which organization and space even, and which foundry they're on. Sorry. Earlier you were showing the Dizzy Lizard app and there was an image, okay. So this one was pulled from the GitHub API because that's my face on GitHub. And when we were actually deploying it, let's see this again. So that's just your GitHub profile? Yeah, exactly. Now, in a previous version of this, an old, sorry, an old version of the UI that we worked on, we actually had gravatar support for the users so that when a user logged in with an email address, it would check and see if there was a gravatar enabled for that and they would actually have their picture on it as well. So you could see in the timeline who had deployed what, so it was really useful. I just wanna make sure that I don't forget to show that we are, we wanna, we're here to get your feedback. We wanna get your pull requests and your enhancement requests and we want you to join us on the Stratos Slack channel. And this is where you find it. Thanks very much for your time today. Thanks for bearing with me with the AB issues.