 Hi, thank you for joining us for Newton design series on triple O and with me. I have Steven Steven. Can you please introduce yourself? Hi. Yeah, sure. My name is Steve Hardy. I'm a software engineer at Red Hat And I've been involved with open-stuck since about 2012 Originally working primarily on the heat project, which is an orchestration project and more recently involved with the triple O project And on the PTR for the Newton cycle Great. And can you please give us a brief description of what is triple O from a project perspective? Yeah, sure. So triple O is a deployment project and the aim of the project is to deploy open-stack services for production uses and It's kind of different to a lot of production tool chains in deployment tool chains rather in that we actually use open-stack services to deploy open-stack Where possible and that's where the name comes from. It's triple O open-stack on open-stack And so for example, we use heat to do orchestration of the deployment and Deploy the nodes and configure the services and we use ironic, which is the bare metal provisioning Component of open-stack and we use that to provision bare metal nodes So we use a number of other open-stack services as well for the various pieces of the deployment tool chain Got it. And so we're about a month after the design summit that happened in Austin Can you please share a little bit about what were the hot topics your team discussed and what were the potential outcomes from those discussions? Yeah, sure. So we had really productive summit and some of the major topics we discussed were around Upgrades and so in the previous cycle through Liberty and the Tarka We got to the point where we had a functional upgrade support for version to version upgrades But we were looking for ways to improve CI coverage of that and also to kind of break down the implementation So it was easier to specify per service and upgrade behavior at the moment the implementations a little bit of a monolithic Approach and so that was one topic. The other one was kind of composability and just providing more choice So this ties into sort of decomposing the upgrade implementation for all of the service configuration as well we want to allow Having a snippet of data that explains how to say deploy Glantz API as opposed to having one big monolithic implementation And again, this is about allowing people more choice in terms of which pieces of open stack where we want to deploy and also potentially More flexibility for folks who want to kind of integrate some new service just making that simpler And the other thing is kind of usability and we had a good few sessions on a new API which in the triple open stack on open stack theme is using the Mistral workflow component of OpenStack and we're expressing an API in terms of Mistral workflows and custom actions and Also, we're working to provide a UI Which is going to just allow easier proof of concept deployments and Just a basically an easier operator experience from an user interface perspective There was also some really good term discussion into containerization. That's a hot topic in OpenStack generally and there was some good discussions with those in the caller community in particular Just trying to figure out the next step for containerization and triple-o and ways which we might collaborate between the various teams Who are involved with containerizing open stack? We've already got some container integration and it's really a question of how we evolve that to become More fully featured over the next couple of releases Got it. And so that seems like definitely a productive design summit session What are some of the user needs that you've identified that you want to work on in a Newton cycle? Yeah So I mean it kind of ties into a lot of those session topics in that you know for a deployment tool chain one of the key Requirements is providing a good upgrade experience and trying to minimize downtime And so yeah, one of the operator needs there really is just kind of providing a smoother and more well-tested Upgrade experience and so we've got kind of the v1.0 upgrade implementation in place and it's a question of how we evolve that to improve the experience for operators and that includes things like getting better coverage of Version-to-version upgrades in our CI system. And so there's been discussion around how we standardize on You know open stack in for a tooling and improve sort of reuse within our CI system The other one is kind of just enabling more choice until recently triples had a fairly monolithic Kind of opinionated deployment of open stack and feedback from operators has been that they want ways to enable more choice So they can wire in extra services more easily They can reconfigure things more flexibly and also control placement So for example allowing independently scaling and services onto additional roles or even wiring in completely custom groups of modes For example to run the party SDN control of services and those kinds of things And so yeah, the composability kind of ties into the kind of like an operator Flexibility, but at the same time we try to improve usability. So that's kind of polishing the command line user interfaces and building out a new UI system which uses the Mistral based API referred to earlier on Got it. Thank you and So out of everything that you've discussed already and possibly things you haven't discussed so far What are the top two priorities? Whether they're new features or enhancements to existing features for triple-O in Newton? Yeah, so I think I mean it really boils down to Two or three Main priorities one is kind of CI reliability triple-O runs its own CI cloud because we need to support doing ironic metal provisioning tests. So similar to some other deployment projects. We end up having an independent CI system So we've been trying to improve the capacity there just to provide faster and more consistent results in CI And the other one as I mentioned is kind of finishing upgrade support or improving upgrade support such that we can have that as You know really well proven part of the tool chain and then the sort of composability model We're investing a lot of effort into refactoring our current implementation such that it becomes much more pluggable So the idea is to evolve towards having kind of a plug-in Format for triple-O such that if you want to deploy any kind of service on your open stack cloud You can do so very easily and have kind of a flexible sort of plug-in based model And we're doing that by a kind of a composable heat template model again The sort of thing is we're using open stack components and hence we're using heat as the primary interface for that at this point Got it. Thank you And so the product work group has been using the notion of themes which right now are things like scalability resiliency Manageability modularity and interoperability. What would you say is a key theme or themes for for triple-O in Newton? So I guess again it ties back into some of the things we've already discussed I mean upgrades which is kind of related to usability And then usability more generally so the first thing would be usability And that ties into kind of like the day one experience just kind of nice easy views for proof of concepts deployments and kind of flexibility in terms of you know more advanced operator usage the next one is Composability so I mentioned that in relation to Usability that's that's really just more about providing a really flexible platform. So we're trying to build a framework That is going to enable operators to define their environment that they're deploying in any way they choose So they can flexibly define the way the networks are wired in The roles and groups of nodes they want to deploy and then the mixtures of services and how they're deployed So I would say yeah usability and composability are two Primary themes we've been focusing on great. Well, thank you for joining us. Is there anything else you'd like to add? No, I'm pleased to talk about triple-O. I can just say that if anyone's interested in trying it and have a look at the triple-O docks repository in the open stack org and there's also Pound triple-O IRC channel if anyone wants to drop in and ask any questions. We're always so happy to help Well, thank you so much for your time Steve No problem. Good to talk to you