 Welcome everyone. It is Matt McEwen, who seems to be a resident of this room at the moment. What we are going to talk about today is where we are with Openstack Helm, where we've come from, and I think that one of the best ways of talking about the program is firstly starting with the mission of Openstack Helm. ac mae'n rwy'n meddwl o'r rhaid i'wch ei bod i'w ddechrau'r llifwysig, sy'n buddwydau, ogi'r flod, yn fwy o'n gwblio cyfnodol, a'r hubau yma i'r syniadau cyfnodol i'w cyfanetau. Mae'n meddwl i'r wneud i'w meddwl i'w meddwl i'w meddwl i'w meddwl i'w meddwl i'w meddwl ar hyn o'r ac oes gen grapes at y gynllunio gyda'r eithaf o cyrfat cynlluniaid cyfilio cyfosigol. Mae'n rhoi bod'n cyfosigol o'r tires y bydd wedi'u'r morthedig. Mae'n rhai ify bent â wahanol â dynion ydw i ddau i ddŵr, a'r wneud hyn i'r wneud efallai i weld yr ysgrifennu ddefnyddio'r pethau yn ddau, neu mae'r cwestiynau gwlemp ymlaen.�esaeth o'r fyrdd ydw i ddelw i gyrwch cyfosigol ar gŵr dim iawn, was a really really scary thing to do. They involved an immense amount of time and planning and it was very hard to do in a repeatable and declarative manner and this was something that we sort of quite quickly identified when it appeared on the market that Helm appeared to be quite a good solution to this and it kind of led into our unofficial mission statement which I'm really glad to see airship adopting as well and that we're looking to try and essentially be boring. I mean at the end of the day open stack operations is something that you definitely don't want to be exciting and you want to have a cloud it should be a stable cloud one that you can manage upgrade and be usable without having to stay up all night and you know deal with angry people on the phone and so we kind of started about 2016 very much as a as a proof of concept and we moved into open stack infra in July 2017 as an unofficial project and in October last year we got official status and at that point Matt assumed the role of PTL and really sort of guided that project out out from the shadows and into the light you know in the sense of trying to take some of the initial stuff we had done bring some sanity to our documentation our gating and then another thing that happened sort of alongside that was the collection of projects that we we had also developed partly within well within AT&T and with with support from people like SKT collected into a form airship which which obviously people that were at the last session should know quite a bit about. We still haven't had our 1.0 release and we're looking to try and do that at some point towards the end of this open stack development cycle and we've got we've got a few things that we'll touch on today that I think we need to address before we do that in order to be able to provide and support within the community a something that we we're very confident that the sort of API won't change significantly and will allow us to deliver on that promise of you know supportability and essentially boring operation where things just work and we've had quite a lot of impact across different projects and we originally started using cola containers for for everything and as as time went on started adopting Loki which was a new container project that formed that helped us produce some light lightweight images with potentially slightly less opinionation to them than and came with cola which was sort of one thing we were really keen to see where we can have a bit more flexibility and a bit more lightweight around there and so we during the last cycle adopted those as our default and they're now really really seeing some great success with them and additionally there's quite a few projects that have started using open stack helm as as well as ourselves I mean airship in particular uses the keystone and Barbican charts I think as Mark and Matt touched on they use the helm toolkit that we developed which is a series of macro functions and helpers essentially a library for helm to help them with their chart deployment and they also make use of some of our gates and checks in their zool infrastructure and the other incubator project within the foundation styling X is starting to move towards using open stack helm for its life cycle management of open stack components and it will also be using I believe Armada up from airship as well to help them in that journey and then Juniper and the tungsten fabric community are running a fork of our Nova and Neutron charts and they're also making use of helm toolkits and the patterns that we laid out air for for their deployment of their products on on Kubernetes so the question was is why does their tungsten fabric use forks and not the same charts that's that's a good question I think they feel that they're not yet at a stage where they want to upstream their work they they have some changes that they've made to Neutron that they're not yet comfortable with trying to merge upstream although I've I've reached out and encouraged them to do so so I'm hoping that over the next couple of weeks if not months that that situation will be reduced because at the moment it is running alongside in parallel whereas we merge things there they're essentially taking air cherry pics of of everything that we do and and putting that into their own stuff which is on one level great but it would be nice to have a canonical source for for all of that stuff so over over the last release um sort of because one one thing I should sort of emphasize as well is that we're we operate in a release independent um category so we don't actually tie ourselves to open stack releases and when we when we do eventually get to the stage of cutting our first release we don't have any real intention of directly following open stack releases other than ideally defaulting to deploying the current open stack release but because we have engineered our charts to support multiple versions of open stack we we don't feel that it's quite right us following that approach um but over over the last cycle we split our charts into multiple repos so we have our primary repo where we contain helm charts for open stack official services we have a info repository where we do all of our supporting services for open stack and logging and monitoring and alerting which we view as a sort of critical part of a production ready open stack deployment um and we also contain most of our our gating infrastructure within there and then an add-ons repository where we have some other things that we view as being quite important for any large enterprise or organisation that's wanting to run open stack things like charts for artifactory and Jenkins that sort of tie neatly into the rest of there the the ecosystem that we're building um we also dramatically improved gating um and actually provided some um there's still a very long way to go and that that's something that I think we definitely need to do a huge amount of improvement on in the future but we're now on every patch set into open stack helm launch each of our charts and then do a validation test in the form of launching a vm ssh'ing into it and attaching a cinder volume um and we moved from the defaulting to the newton version of open stack to the okata release but I think our primary goal in the last release was um concentrating on stability um and if anyone was at the the keynote that AT&T did the other day you know it's a demonstration of that because at least for some organisations and I think some other telcos are doing the same this is now moved out of the academic phase and is very much moving into production um so it was very much about sort of in getting that resilience that we needed and as part of that providing LDAP integration across all relevant components so it could tie into an IT organisation's infrastructure we do we do still support newton um we we need to actually decide at some point how long we are going to maintain that support for because there are things like the the changes to sales v2 that weren't fully fleshed out in newton that are in okata and onwards so we're we're sort of at that point where we need to work out how much we want to maintain with our current charts compatibility across all open stack versions and how much we want to be able to take advantage by default of some of the new features that are available in new releases of open stack at the moment sorry the question was is which version of open stack do we support at the moment we are gating for basic functionality on newton okata and pike we have a patch set in place for queens that just need some polish and we also have contributors who are running master but we don't yet have in place the sort of infrastructure to build images for that and test it so we can go in theory we can go right to the current tip but but we need to improve that that posture and that's sort of where where we are in terms of open stack releases ties in quite nicely to some of the stuff we have been doing so far in the in the current cycle where we have added two more repositories the images repository where we are going to take the limited number of custom docker files that we have for open stack helm things like libvert and mariah db and place them into a repository so that people can build them and we can start providing support for multiple distributions rather than just the ubuntu distribution that we support at the moment and then another repository for documentation for all of the projects as we start to spread across things and on this I'm really particularly excited because we have quite a large number of contributors in Asia and so hopefully we should be able to get quite good Korean documentation in place which which will be really really nice to have as a project the other thing that we've added is and started work on is improving security where we now support TLS on all external facing traffic to and from the cluster and then in current development and sort of which is live at the moment we're starting work on their support for multiple distributions in the charts and I think some some members of the community like JP at the frontier is starting work on getting support for SUSE in place and it'd be great to see CentOS and other things coming as well and hopefully the images repository and some some more work that we're doing under gating will help there and we're also adding internal TLS including certificate management via by Attila or the ability for operators to bring their own certificates for all internal things so that's both going to be breast based services and things like Mariah DB and Rabbit MQ and supporting credential rotation which is something that we anecdotally support at the moment for Keystone there are some gray areas around Mariah DB and Rabbit and again this is something that we need to actually get gated and validated that we can we can do and then as I sort of just mentioned where we're starting work on an images repository but we also need to start caching images both in our gating environment and as well within the cluster to try and reduce the burden as things get distributed around especially with large numbers of nodes. The question was is airship providing this sort of caching um no is the is the simple answer in the sense that we will develop a a chart for a local caching repository which would be part of OpenStack Helm Infra and then most likely airship would leverage that chart as part of its deployment and use use that component I mean in in many ways I think this is a gross over oversimplification but OpenStack Helm is a project that provides batteries and projects like airship or styling x you know provide something that those batteries go inside is the easiest way to think of it and then the last sort of thing that I think we really needs to work on because it's a very pressing pain point we have at the moment is improving our gating situation our gates at the moment on one level are quite effective because they provide pretty good validation that a service is functional but they also are greatly impeding the ability for developers to get their work merged and the rate at which they're able to go because we are we need to do some work about optimising what we're gating for how fast those gates can run as a result and also getting better feedback from those gates so that developers can see what changes they need to make in order to get their patches merged and so I I'm very I'm very keen to see that that improve it kind of brings us on to sort of the future of where where we're planning on going and we we're looking at and would like to get unit testing on a lot of our helper functions that we have in Helm Toolkit and there's a there's a unit testing framework for Helm that's emerging and we also need to have a look at Helm 3 as that starts to develop it's under a very very slow development at the moment and it could have a few impacts for us in particular it provides support for lower scripting as well as go tpl templating and I don't know if anyone on the team has really had time to look at that yet but I think we need to evaluate what's that what potential advantages we have and if we want to start supporting lower in our in our charts as well moving forward and and then there's obviously you know a lot of hype around service measures at the moment and you know we we've done some sort of informal evaluations of sort of what what they potentially would provide us you know and things of things like API services where they potentially would be a good fit and then you have agents that are running on the nodes and here a lot of the support that we kind of see for things like STO and Envoy and similar systems are probably not going to sort of help us much there in terms of providing secure communications when things are running in the hosts networking namespace so it's it's emerging and something that we definitely need to keep on tracking but I think at at the moment the consensus seems to be that they're fairly immature for for our sort of use case and then when it comes on to both images and the charts themselves it would be ideal to start publishing those from within open stack infra and on a periodical basis so that we can take advantage of security patches and things when they come out and then the other the other sort of aspect of where we're looking is you know things things like operators and how how those sort of potentially fit into the picture I mean they have really emerged over over the last 18 months as potential ways of solving a lot of problems within Kubernetes and you know they whereas whereas sort of six six months ago they were still a slightly academic phase there's now definite acceptance of them within the Kubernetes community and a huge shift towards looking looking towards them and they they offer some really good advantages for things like state management however there's still some concerns about sort of the ability for an operator to interact with many things well a human operator to interact with many things that an operator produces so if if you were going to look at things then then there can be some impact there and so there's a potential for using them for managing open stack objects and bootstrapping services but it's still very early and the question was sort of how how do operators relate to Tilla I think they serve two separate use cases where operators are very good at sort of managing things that don't fit within traditional Kubernetes objects whereas Helm is very good at templating and easing the management of Kubernetes native objects for applications that fit them well so so that's sort of where where the difference in their lives and then the other the other thing that we're sort of trying to work on a lot at the moment is trying to engage project teams more so that we can gain from their experience in particularly areas like Nova and Keystone so that we can improve the feedback loop improve the quality of our deployments and and hopefully gain more adoption from those communities as a as a sort of preferential way of deploying and managing their services okay and I suppose the last last thing is is we have an OpenStack Helm channel on IRC and we hold meetings every week 3pm UTC and OpenStack meeting 5 and you can also reach us via via the OpenStack mailing list we've also got a onboarding session at 20 pass 3 for having having a look at how you could start contributing to OpenStack Helm and also in that session it'd be great to get feedback on any any people that have used OpenStack Helm at the moment any pain points they've had or opportunity we have to improve things okay and are there any questions or so the question was with a 1.0 release is there any plans to synchronize that with the airship there are no plans directly I think I think the way that sort of the everything will land is they will most likely happen around about similar times but because they are in essence separate projects there is no coupling between those two events other than the fact that many of the people working on them have the same sort of imperative to try and get things stabilized around about the same sort of time but but they are two separate activities from that perspective oh so thanks everyone