 Welcome to the PTL webinar series. These series evolved from sessions that were held by the PTLs regarding updates to their projects at each summit. And we've converted that format into webinars to extend the reach of events beyond the summit. And today our PTLs are going to update you on what may be new for Juno, our next release, as well as detail any items of note for our users and operators. I'm Margie Caller with the Foundation. Allison Price is here as well from the Foundation. And we're going to run the webinar. And today joining us as well are the three PTLs that we'll be presenting to you. That'll be Dolph Matthews, 1T. He's the PTL for Identity slash Keystone. And then we have Mark Washenberger for Image Service, codenamed Glance, and Ann Gentel from the Documentation Project. I don't know if there's a codename, codenamed Docs. So everyone's line is muted. I'm going to start with Dolph, moved to Mark, and then Ann. So Dolph, when you are ready, I am ready. Cool. Thank you. So I'm Dolph Matthews, Program Technical Lead for OpenStack Identity. Hopefully today I'll be able to convey some of the more interesting directions that Keystone is setting during Juno. And several of these should be familiar as they're ongoing themes from after release or two. So during ITOS, the Identity Program established an official mission statement. So I'm going to just take a minute and share that. Especially if you're not familiar with the Identity Program and the Keystone Project. So at the end of the day, our goal is basically to carry out as much of the burden, to carry out as much of the burden surrounding Austin and Austin as we can so that other projects don't have to do it themselves. So we recognize that Adderay Cloud has the same authentication requirements and that every service has the same authorization requirements. So we've made pluggable solutions to both of those problems. We also advertise services provided by the cloud to the end-users as a first step towards users being able to navigate and interact with the cloud. It's also worth noting that we're seeing more and more of the focus on auditing as our cross-project effort, but those contributors tend to come from Keystone's own community. So from a community perspective, we're very much edging towards traditional AAA. We want to be confused with AAA. So Federated Identity. So Keystone itself can stand in for many deployments as an Identity Provider all by itself. We've always recognized the need to start federating out to existing external Identity Providers and abstract that away from the rest of OpenStack. So in this house we finally shipped an API extension called OS Federation, which provides Keystone with the necessary plumbing to map externally verified Federated Identity information into Keystone's existing model of multi-tenant authorization. So for external verification with SAML2, for example, which was the first use case we wanted to tackle during I-COS, we currently depend on a popular Apache module called Shibboleth and that you deploy Keystone on Apache. Behind Apache, everyone will get it. We're now looking to leverage that groundwork to establish first-class support for both OpenID and Kerberos during Juno. And we're also looking at approaches for allowing one Keystone deployment to trust tokens issued by another, which would basically mean that one or more remote Keystones could act as your local Keystone IDPs. Compressed PKI tokens. So for some quick background on this topic, especially if you're accustomed to UDYB tokens, PKI tokens are large, base-64 encoded, signing JSON objects, containing identity, authorization, and audit data, usually along with a catalog of accessible web services with a service catalog. The varying size of PKI tokens tends to be alarming for users coming from older UID deployments where tokens are just a constant 32 characters. So it presents a little bit of a user experience issue, but the PKI tokens can be so large that they can actually prompt into limitations and, for example, Apache. So looking at different options to reduce the size of tokens and compression just happens to be one of the first steps for taking them in that direction. So hopefully we'll see PKI tokens continue to shrink over the next couple of releases. It's also worth noting that you'll see this feature referred to as PKID. I'm going to go back on to that, which is an audit underlying implementation, the fact that we're just adding zealot-based compression onto your regular PKI tokens. So token revocation events. This was a big feature from ISOPS that we landed on, but we're not actually using it yet. So in prior releases, Keystone has published a token revocation list, and it still does, which is a giant list of revoked bearer tokens. So, for example, if you're using PKI and delete a domain, we will generate a gigantic list of all the tokens attached to that domain that are now invalid and then push that out to the other services. So that alone represents an attack vector. It's super chatty. There's some network load there, and it's a big reason why we have to persist PKI tokens to the database in the first place. So as I said in ISOPS, we now have a new approach for that, and instead we're publishing descriptions of the events that result in token revocation rather than lists of the tokens that are revoked. So our next step during Juno is to start using that information to validate tokens for other services. So then the token revocation list basically becomes redundant. We can turn that off. We've also been slowly moving towards a model with completely non-persistent tokens where the player is going to opt to not persist PKI tokens at all. So as a player, that means no more token cable to fuss with, no more token flush command, no more crown jobs, et cetera, et cetera. Keystone's load and performance all improved. And hierarchical multi-temperacy. That's a big topic for last. The idea of hierarchical multi-temperacy is only then seriously put around the community for a couple months now. And if you follow it along, you already know that the dish has a fantastic or a bigger pitch for the future, which I'm not going to try and replicate. But the short version is basically that we could potentially support in this organizational complexity for resources and open stock tenants or projects, rather than a relatively flat domain project multi-tenancy model that we have today. So one of the use cases we're looking at is resellers, for example. We've seen some prototypal work already, and I expect that to continue throughout Juno. But there's going to be such a dramatic change for open stock as a whole that I'm definitely not going to make any promises that Keystone is going to deliver anything during Juno. And part of the reason why I say that is that it's an area where you have a laundry list of new use cases that's pretty concerned with the things we're looking at and things that we need to better understand in order to actually support them and implement them correctly. So if you follow into either of those categories, we'd love to have your feedback. That's all I really have. I don't see any questions in that chat. I'll wait a minute. Otherwise, I will hand you off. Okay. People can ask at the end as well if you have any questions for Dolf. Thank you. Sure. And then Mark, I think I'll turn it over to you when you're ready. Mark with image service slash glance. Okay. Can you hear me already? Yes. Okay, great. So thanks for the instructions, Marguerite. Again, I'm Mark Waschenberger. I'm the PTL of the OpenStock Images Program, and I'm here today to give you the Juno update for what we're working on. So for those of you who aren't maybe already very familiar with the Images Program or, again, the chief project in this program is Coding Glance. I've given you our current mission statement. We also, like you guys in the program, adopted our mission statement from what recently. And just to give you a sense, I mean, what we do is we focus on bootable disk images, storing them, routing them, making it so users can share them and manage them and distribute them across the cloud. So a bootable disk image in this context is really something that, when a user shows up to Nova and wants to start a server, they're providing a reference to a disk image that lives somewhere in there. So we're sort of the starting point for Nova instances. The first thing I want to talk about today that's kind of on our list for Juno is that we're actually adopting a new mission. The idea is to kind of expand our scope somewhat to serve other projects. During the past two cycles, there's been some discussion about what kinds of opportunities are out there for different services, such as heat, et cetera. And so to take a look at the next slide, you can see kind of a glimpse of our new mission, sort of a trimmed down version. The main change is to no longer have a narrow focus on bootable disk images, but to focus on a broader category of objects that we're calling artifacts. Now this concept of artifacts does include bootable disk images, so we're not abandoning the story that we had before. We're just expanding it. And so let's talk a little bit about what an artifact is. It's a kind of generic concept. It really can be kind of any sort of sixth data asset, something that's not immutable strictly speaking, but any kind of change to it is a new version. We focus on this versioning story because it's so important for the consumers of land there's kind of two chief use cases, people who want the latest thing every single time they go back to fetch it. They like the latest Ubuntu server, the newest kernel patches for example. But then you also have people who are serving mission-critical applications who have done extensive testing with a given resource, and they want you to get the exact same version that they got yesterday. So we try to support both of those use cases and expand that out to artifacts. Another one of the key attributes of an artifact is that it's strongly typed. We really want to make sure that people know exactly what they're getting and that there's a schema for what they're getting and that schema has descriptions. We're trying to make sure that if say we're identifying an artifact as a bootable disk image that you know it's going to be one of this small set of six types of things just so that people know how to deal with it and so that the operations on artifacts can be sensibly defined. And so while again this can be any kind of artifact type release, we're focusing on things for now that are consumed by open stack services. So on the next slide I've got a few examples of what we're looking at. So disk images are artifacts. We also want to take the idea of a disk image and expand it out a little bit. Still working with NOVA to describe more cleanly the concept of a device layout. So saying DevSDA maps to this device with this image say DevSDB maps to this assembly drive, etc. Those kinds of concepts need a clean, clear representation so that people can reliably boot them in NOVA. We also like the idea of expanding out to machine templates in case you want to use glance to describe things like complex NUMA arrangements or processor attributes. A lot of things that are living in extra specs and flavors right now we think could become artifacts that could be linked to how you boot your instance. And then all that's a little play in the sky. The thing that we're focusing on most aggressively in the junior time frame is actually storing heat templates. And that ties into something that I want to say about artifacts. Artifacts can be like disk images. They can be very large and essentially opaque bits of data, you know, gigabytes say. Or they can be much smaller and very highly structured, same like the JSON or YAML document that goes into describing a heat template. So these are the examples that I have for you now. The truth is that we have several more that we're looking at for almost integrated OpenSec services such as Milano packages, there's some time with Solum, etc. But you can read more about that on the list. So the next item is some other discussions with Juno and it looks like we're going to be looking over to some degree in Juno something that we'll call the metadata catalog. This idea of a metadata catalog actually comes from a pretty advanced proof of concept that was demonstrated and presented at the Juno Summit and it was known as graffiti. The basic idea, I think we see on the next slide, the basic idea is that across OpenSec services different resources have continually used this idea of user metadata and tags. This is a very free-form concept. You basically can put any kind of metadata you want on a server or on even an image or a flavor. But with it being so free-form however, it runs up against the fact that sometimes you need that free-form data to be just right or at least somehow consistent across resources in order to use it correctly or in order for the service to pick up the significance of it correctly. So the idea that the graffiti people had was to create a service to track the applicable metadata and tags across those resources and I think across the new artifacts that we're adding so that in Horizon you can have a really great user experience where you're looking at a resource and you can see what kinds of metadata you can apply to it and you can see what that would mean. I really encourage people who are interested in this to take a look at some of the videos that have been put out by the graffiti team to get a sense of what they're driving at. You can find links to that on the mailing list. Finally, in IceHouse and somewhat in Havana, we've been working on some of these asynchronous operations. Chiefly, we want to support the concept of image import and image export. Finally, I think at a point where we can move ahead and really fully support these use cases and this is something that is really important for OpenStack because I think it plays in directly to our ideas around interoperability across clouds. Sometimes today it's very hard to have an image that works in one cloud work in another cloud. By working on import and export we should be giving employers and users the tools they need in order to ensure that an image that works in one place works in another. That's our vision looking forward for Juno and what we'll be working on. There's a lot more that goes into it but those are sort of the big ticket items. I'm not sure if there are any questions at this point but I'm also happy to take questions at the end. Thank you. I don't see any questions right now. Okay, perfect. Well, thank you very much. Thank you. Thanks, Mark. Anne, I'm going to pull your presentation up. Great. Thanks. Then we can get going when you're ready. There is no coding for the documentation program, it's just docs. I like that. Right. I'm Anne Sunall. I'm the currently documentarian. You've probably seen on the mailing list at this moment. I actually had a look up how long has documentation had an official program. We've had a program since July of 2013. Our mission is to provide documentation for core OpenSec projects to kind of scope narrowly so that if we can document integrated that's awesome but we also are here to coach all the projects to provide tuning in processes and just best practices for quality and accuracy and basically treat the docs like code. So that's our mission and I'm going to walk through a little bit of what we did in Ithouse and then also what's coming up in June. So what happened in Ithouse? Well, we actually had nearly 200 docs contributors and when there's 1200 contributors total, I'd love to see more like 600 doc contributors but you know what, I feel really good about the kind of products we're making. So this is just a list of the new things we were able to deliver in Ithouse, the new automatically generated configuration reference. I think it probably documents over 6000 options across all of the integrated projects. So that's pretty amazing and that's probably the only way to keep up with all of the configuration options. We also added a new upgrade section so that's typically lagged really far behind but now there is an upgrade section in the operations guide that's fully tested both on Ubuntu and Red Hat and so there's also in the work now upgrades from Havana to Ithouse. So that's about the earliest we've ever been able to write upgrade notes accurately and then I don't know if you noticed the big flash of the summit but we had an O'Reilly custom edit on our operations guide that we originally wrote with a book sprint and so that was super exciting to work with a developmental editor who's had a lot of good suggestions on where to add, where to invest time and resources and also just a really great cleanup, new images all throughout that are very consistent and an index. So that's kind of exciting to a book nerd like myself. We also added an SEK chapter to the user guide that's got Python specific examples and we're continuing to add to that. There's also a long reference listing that's in PDF so if you need to get on a plane and look up API reference information that's now possible. And then one of the great ones in the Ithouse release had to be that install guide just getting an architecture that included Neutron all throughout but also still embodies Nova Network but let's people really try open stacks from the standpoint of getting it on a couple servers, kicking the tires and knowing enough to make good decisions later. We closed a lot of bugs too. We tracked doc bugs just like code defects and we closed nearly 400 doc bugs. So I just have to give props to the team who makes all this stuff happen. And it's really starting to play off. The first time the user survey reflected, and I mean I love the user survey because it really gives us the input that we need and sometimes a kick to try to reach the next level. And this time someone even noted we've seen the documentation improve significantly and others are holding it up as a model to strive for. So these are the kind of things we're thinking about and keeping on working on. So what's coming up in Juneau? So what I did after the summit is I collected all my notes and sat on the airplane and wrote out a roadmap for all of the documents that we currently maintain. And I don't know if you've heard me say this before but it opens back doc. We really want to document open stack. And so we document the integration. We document the points where people are trying to deploy and administer an entire cloud. So not just Nova, not just Swift. And so that's what I'm going to walk through is these roadmaps. I'm going to give you some information on a book sprint that's coming up. I'm going to talk about how we're kind of re-teaming the security guide and the training guide. And then also talk about how I want to keep improving the user docs and how we might go about that. And then also developer.openstack.org. What can we deliver that last release? How can we continue to improve it? And then always circle back to API documentation. So let's go ahead and you can go next to the roadmap slide next. So I kind of grew our documentation into two categories mostly by audience, right? So we have a sort of admin and deploy doc. And I tell you, the install guide has a brand new blueprint to really do a deep, deep consistency level output to get sample output everywhere, to get sample config files everywhere. And we actually made a decision at the summit to remove the open stack config command so that people could see this is actually what I'm editing in each of the config files instead of trying to hide it behind like a credini configuration guidance. And that's a tough decision. And we've kind of walked around it for a while but I was really proud of the team for picking it out and having that decision done at the summit. And we still had to discuss more on the mailing list but it just felt good to make a good decision about the install guides going forward. And that support has been doing amazing in the last release and continues to do so in this release as well. And then I think the rain is on the line. Thank you so much. At the summit we decided we wanted to show in the documentation which options have been renamed or which options are now deprecated in a particular release. And so he's been working already on a blueprint to get the configuration reference to show her project what has changed. And I think that's going to be a great addition. That's a brand new guide and now we're going to keep improving it in Juneau. And then we have an admin user guide that shows not only the dashboard admin task but also what you can do in the client tool. And so we're going to keep adding to that how to monitor usage. Even more on clotamine as it's already addressed in there some. And also we're keeping an eye on the mailing list and going to try to add more examples of what people are asking for. And then we've also got some nice migration kind of information so that people understand what am I, when I have to completely evacuate a host what does that look like. And try to do a deeper dive into the data today. Well, I hope you don't have to evacuate a host day to day. But the kind of tasks that admins have on top of their minds, right? Now we also, confusingly enough we also have a cloud admin guide. And so this is that giant guide that keeps getting added to over time. And one of the things we're probably going to do is a blueprint to break out a networking admin guide because enough of it is just different enough from general cloud admin work that we're going to try to assign some resources to get some really awesome networking day-to-day networking best practices all geared around OpenStack. And so Lana Brindley is in Australia and working on a book, like Swarm kind of day after PyCon Australia. So that in August we can kind of get that book really on its feet. Two others that I didn't mention, not that they don't have road maps so that these are not ones we're necessarily focusing on greatly in Juneau, but we also have a high availability guide and we have a virtual machine image guide which both are very highly read, but I just don't think there's a ton more work to do this release and we're trying to focus in other areas, especially towards users and people who consume application developers. Yeah, we can go on to the road maps for the user guides. So we have a giant CLI reference now and it basically gathers all of the Nova help commands into one space so that you can have a big reference listing. And I think even bringing all that together has helped us even log dot codes about even what Nova Network does and what would be the different listing of network commands do. I think that's been really helpful and what I like to see happen with it is we'll keep adding the integrating clients. Trove was recently integrated and they were like, oh wow, our stuff's already in there. So sometimes we get those kind of quick wins where we're able to automate enough to get really useful information right away that's integrated with the rest of OpenStack. And the user guide, we've had a really interesting conversation on the mailing list, the developer mailing list about what to do with the user guide next. Right now it's in the HEAP project, in the HEAP repo, and they automate a lot of the template reference. So what we're trying to figure out is is there a way for us to automate the template reference to get it into the user guide format or should we actually move the user guide into a different format that would then enable to make it easier for everyday developers to contribute to the user doc. So I think that is a really exciting aspect is I really want to start enabling more and more authors, and so a lot of the work I did pre-summit was trying to survey documentation people trying to get a sense of what people actually prefer to offer in, how we can make our tooling still deliver exactly the deliverables that everyone expects and the high quality that everyone expects while at the same time finding ways to enable more and more authors. So I really am going to try to figure that out, and even this morning, I had a conversation about this early on. What is the best answer? And so I think it's great that we're having these good conversations early on, early in the junior release. So now those are the roadmaps for each document that we tend to think of as like end user or admin and deployers. But we're also going to work on a guide that has not really been written before in OpenStack. And that is an architecture or design guide at the production level. So how can we create a Bible for OpenStack Architects? How can we create even the deepest detail of how to configure a cloud to do particular things, starting probably with use cases of we need to get this done in a business setting. And Tend Wee has done an amazing job of organizing beforehand, gathering a team of authors who are ready to take on the challenge of writing a book in five days. And I'm just so impressed with the bravery and also just the knowledge that we're going to gather in this room. And it is really awesome. And VMware is hosting. This is going to happen July 7th through 11th. And probably literally a week or two afterwards we should have this book ready to download from the doc.openstack.org site. So this is very exciting and I'm just really grateful that this team has collected and that Tend was able to put it all together. So thank you. And thank you to the foundation because we always bring in a book sprint facilitator. Someone has done these over and over again and did our operations guide and did our security guide. And so Adam Hyde is going to do that again for us and we're just super pleased to I just can't wait to see what comes of it. Now another one that and the next slide we're going to talk about is the security guide update. So Brian Tain and I met at the summit and he was one of the original authors of the conference. They had about a dozen people there and so we're looking for ways to do updates for our ice house. And there's a few doc bugs a lot against that book but for the most part, man, it has stood this test of time and he's had really good input from people saying, you know, this is how we do these things. And I'm just super excited that they're going to start to do updates. So we're looking for the separate team to really be subject matter experts and then what we plan to do is the other tech security notes are currently published on the wiki but ideally we'll be able to do a postage proctor for those becoming appendix on the open tech security guide because you always have that reference immediately if you need it. And then another team we're standing up separately from core docs is a training guide team and so this team has done a lot of work to get different paths that people can take to see a guide, a developer guide and working through all of the various ways that you might walk up the open stack and see how to learn open stack. So Sean Roberts has been doing a lot of work here and what we've done most recently and for the Juneau timeframe is move it into its own repo so that people can focus on those reviews, get a separate core review team so that people can really start to think what is a training deliverable beyond just a manual? And so one of the things they're working on is a set of training lab scripts and the audience for those would be someone who wants to be a trainer and wants to be able to set up their own lab so if we can collaborate and build those training scripts in the community anybody could set up their own lab anybody could work on this at home anybody could work on this being able to do the exact commands that you would do on a private or public open stack cloud. So I think that's a really great reboot of this team to try to get really geared around deliverables that are slightly different from just the manuals but deliverables that actually help people learn and teach and meet objectives that can then lead to passing tests about open stack. I mean since Juneau is intended to be really the shift towards how can we enable more and more app developers to consume open stack resources and like I said last release we put together developer.openstack.org but what I want to do next and it's pretty plain vanilla it talks about the API, it talks about the SDK it talks about the CLI but what I really want to do next is let's make that site a true landing page for open stack developers and by open stack developer I do also mean the contributor developer so you might have a landing page but do you want to make open stack or do you want to use open stack and then they would have this entire embedded experience as a developer consuming open stack using SDKs that we have known to be tested on open stack clouds and some part of that is going to be trying to get a simpler offering style in there maybe it's just an RST Sphinx based site, maybe it's markdown Ruby I don't know but the idea would be let's start enabling that entire group hundreds of thousands of users to start writing documentation that helps each other and part of this is that we don't really have a developer experience program and so I'm looking for governance ideas and by governance I mean well how do we get a course out of reviewers on those docs how do we know that people know this works on the PHP SDK and so that's where I'm really reaching out in the community and trying to find out what is the best way to stand up this true developer portal how do we reach out to these developers on other languages beyond Python and then that always leads us to API documentation we are maintaining the API definitions that work across 12 projects so we're probably up to probably 14 APIs because when you count the different versions that each project is putting out at any given time yeah I mean it's also Mark and Nicole now they have two versions of the API version one and version two for the image service and version two and version three for the identity service so we're always working on those definitions always working on the backlog of bugs and also trying to put together this style guidance so if you're an OpenSec developer or you're new to the OpenSec project how do you know the best way to do Mark or limit all of the things that should work consistently across the OpenSec API so we're doing kind of a starting point document for the technical committee so that we can have a checklist for well does it really meet what we originally thought was our style and let's talk about that some more so how does that work also I mean I think the style guide itself is probably a simple governance page but also to put together an API guide that talks about the concepts across multiple APIs the different use cases across multiple APIs and then I can't say it enough we always have bug fixing I think there's 65 open bugs we can compute V2 API docs so that is absolutely something we're constantly going triaging we're outdevelopers these guys are amazing at logging really detailed really well thought out doc bugs how can we keep improving the API documentation so that when someone goes to write an SDK implementation against our API they know and can trust that API documentation so lastly and I think I'm right at 15 minutes sorry guys but I cover a lot but how can you help and I hope some of you are here to figure out where you might fit in the documentation program you can always message me I'm happy to be that first point of contact I get on phone calls a lot I talk to people all the time about their ideas what can we do to implement those and you know if you can't get directly in touch with me I have a team that's always a lot of people are always on IRC and we have a pretty good mailing list where if you ask a question we should be able to get back to you with an answer I write a weekly to bi-weekly mailing list post so actually name what's up doc I am sending out a monthly report to the OPEC doc list that tells all the Google analytics for the past month on the docs.com site we're also very we have very talented developers who work on automation and talented developers working on our translation toolchain for the documentation specifically so I am just always interested in looking for process improvements looking for toolchain enhancements looking for how can we get higher inherent quality by being very persistent with our bug backlog and always looking for new ideas and new contributors so with that I'll take questions and of course now I'll open to anybody asking questions correct? That's correct Do we have any questions? No we don't today and that's okay I want to thank Dolph, Mark and Anne for being the first PTLs to conduct these series I just have a question this is Margie so in terms of developments towards Juno beyond features I know Mark you had mentioned some things about import export with interoperability and bug fixing are there overall trends in terms of how things are changing from upgradeability and the overall projects outside of just features or is it just kind of ongoing extension from Ace House if that makes sense? I definitely think that now that we are able to document upgrades as we go that is a definite improvement I just did a review today of the event of Ace House after Ace House released we had people asking for upgrade documents and we were able to get somebody writing on that right away so to me, upgradeability leads an improvement Great anyone else have any questions? I can unmute people actually You are now unmuted Mines are unmuted if anyone else has questions they want to ask of Dolph, Mark or Anne going feel free to email the foundation as well I can give you that out to the respective person if you do have any questions because I think you will get a follow up email after this call but once again I want to thank Dolph, Mark and Anne for participating today and this webinar will also be on YouTube probably within the next week as well as several more webinars that are to come next week so thanks everyone Thanks for having us Thank you Bye Bye