15:01:11 #startmeeting openstack-helm 15:01:12 Meeting started Tue Feb 12 15:01:11 2019 UTC and is due to finish in 60 minutes. The chair is portdirect. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:16 The meeting name has been set to 'openstack_helm' 15:01:28 hi 15:01:38 o/ 15:01:38 o/ 15:01:51 o/ 15:01:53 lets give it 5 mins for people to arrive - the agenda is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-02-12 15:01:54 o/ 15:02:03 please add to it liberally 15:04:16 o/ 15:05:01 ok - lets go! 15:05:11 wow I see one of our repos inside that list, not sure if it's ready for primetime yet :p 15:05:19 #topic other projects making use of openstack helm 15:05:43 evrardjp: :) 15:05:57 its really awesome to see many projects either using openstack helm, or deploying the openstack helm charts 15:06:26 theres been much discussion and interaction from the airship team here over the last few months 15:06:57 as airship was essentially born out of a need to manage helm packaged infrastructure 15:08:10 and we've had some great sessions with the starling-x team - as they start to use osh to deploy and manage openstack (using armada from airship) 15:09:02 and suse has also started an effort around deploying and managing osh 15:09:23 I wonder how we could do a better job of supporting these projects? 15:09:38 more presence on irc channels/ML would help 15:09:54 I know both starlingx and suse would like to use image distos that are not ubuntu/debian based 15:10:15 and there have been some efforts to get that going, but have essentially stalled 15:10:17 It's not only you, portdirect, and srwilkers that can answer my noob questions -- we should scale the community 15:10:38 portdirect: I cam report on that staling 15:10:42 can* 15:11:17 Basically we got results today! 15:11:27 We can now finally deploy OSH with our current code. 15:11:29 the other thing that would be great is if we manage to get some of the work done in these projects upstreamed as fast as possible 15:11:30 nice! 15:11:39 evrardjp: the floor is yours 15:12:24 So now that the current code is "working",we'll be focusing on a last series of cleanups, and improving the CI, while the team will start building those images internally 15:12:44 assuming the images pass local testing, we'll be providing them upstream. 15:12:53 (no need to worry you with broken images) 15:13:14 with that in mind, some of the people in our team will focus on OSH-images publishing too 15:13:20 so that docker hub will contain opensuse images 15:13:32 It just takes time to put everything together :) 15:13:42 anyway, long story short, we'll be helping you there. 15:13:54 Sadly -- there are hiccups 15:14:05 awesome - i understand that sometimes a downstream approach is preferable for an org. 15:14:14 nice - thanks for the update evrardjp. nice to know it's coming 15:14:30 is there anything we can do in the meantime to reduce the deltas you need to do? 15:14:30 We'll be working upstream first -- but we need to work in a dev environment :p 15:14:33 yes, very exciting 15:15:05 So yes, when we'll start working on openSUSE images, you'll see a few questions popup 15:15:13 sweet 15:15:15 because openSUSE will be different than ubuntu images 15:15:30 I think it would be great to come with a common understanding on how we'll do multi distros 15:15:42 (or multi images, I don't really care the name we gave :p ) 15:15:50 i agree 15:15:54 And to be honest, we might have ideas, but you also have yours. 15:15:55 it would be great to start a spec ther 15:16:13 I think it would be great to sync first, and end up all together in that spec 15:16:22 using your expertise would help us tremendously 15:16:32 ok - I'll make sure its a topic on next weeks adjenda 15:16:46 other than images - are there any other ways we can assist? 15:16:57 eg I've taken starlingx for a spin, is suse's project ready to kick the tyres on? 15:17:09 not yet for now. We have to finish up the last bits :) 15:17:22 but very close 15:17:38 nice - I'd love to get running with it and provide some feedback 15:17:52 its really great to see orgs using osh in so many different ways 15:18:20 its more than we could have hoped for when we started this project :D 15:18:43 I'll also reach out to the starlingx folks and see if i can get them to come along 15:19:02 they have some really nice patches for ceilometer etc, that i would love to see a ps for. 15:19:42 In the long run, you'll probably see more involvement from SUSE,with new charts for projects that aren't deployed yet. 15:19:51 deployed yet in OSH* 15:20:19 is there a roadmap here at all? so we can co-ordinate these efforts? or to early to make public? 15:20:30 (sorry to push you, I'm just excited) 15:20:51 It's too early and very internal. I can just give you where we want to go, and give you feedback update of our time upstream :p 15:21:11 np - i understand - cheers evrardjp 15:21:20 For us having OSH very stable and very updated is important 15:21:38 deploying OSH newton is not important for us :p 15:21:57 I guess you can read the rest between the lines. 15:22:05 evrardjp: what version would you like? If its not communicated its hard to read minds :) 15:22:33 Currently the helm charts are ocata, and we'd like to bump to at least Rocky. 15:22:53 there was a community member yesterday that was interested by Queens. I think that's worth pursuing too. 15:23:01 nice - they should work with that pretty much - I'll get rocky support done this week 15:23:05 I mean ... as a stop gap to Rocky 15:23:17 great! 15:23:20 thanks a lot there! 15:23:31 np dude 15:24:01 at the other end of the colab spectrum i think srwilkers has been working on Monasca? 15:24:33 yeah - been working with it off and on since the PTG, but intermittent is the best way to put it. as other things have been pulling me away 15:24:48 witek: ^ 15:25:16 hi guys 15:25:19 hey witek 15:25:30 srwilkers: could you tell us more about your plan there? 15:25:43 (and the priorities for it, so we know the expectations...) 15:26:26 sure. the plan's pretty simple - i'd like to see what it'd take to get monasca to a point that can work with the current openstack-helm charts 15:27:19 Is there a way I/we can help you? 15:27:39 as far as expectations, i'd defer to witek -- once i've finalized what it takes to get monasca to run with openstack-helm, what's the best way to move forward there? is the plan that the monasca chart would continue to live in monasca-helm, or would you guys like to contribute it into openstack-helm? 15:28:31 it would prefer to contribute it to OSH 15:28:37 awesome witek 15:29:19 :) 15:29:29 is there still a lot missing to work with OSH? 15:29:38 what is the current governance round monasca? I know it was in openstack for a bit, has it spun out like gnocchi? 15:29:40 that was the right answer for this meeting... (god that would have been awkwaaaaard!) 15:30:16 it's in governance :) 15:30:48 https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1753 15:30:49 yes, monasca-docker and monasca-helm were started outside but they use the code from OpenStack repos 15:30:55 witek: i wouldn't say there's a lot missing, it's more just updating the chart to include things that align it with the patterns used in our other charts. things like keystone user jobs, jobs for database management, etc 15:31:04 gotcha - thanks evrardjp and witek 15:31:36 portdirect: to me monasca-docker and monasca-helm don't exist there ! :p 15:31:37 as the monasca chart seems more like a macro chart, as opposed to a chart-per-service approach that openstack-helm takes 15:32:00 srwilkers: would that be a problem? 15:32:10 ie: the monasca chart has templates for a keystone deployment, grafana, etc 15:32:29 yeah we would want to dis-agregate that 15:32:55 evrardjp: umbrella charts are awesome for day one - a nightmare every day after 15:33:05 portdirect: ++ 15:33:12 I would have guessed too 15:33:26 let me rephrase my question 15:33:43 would that be a no-go for starting to work together on upstreaming the monasca chart into OSH 15:34:06 quite the opposite - i think it would be the place to start 15:34:13 srwilkers/witek ? 15:34:14 do you have some intermediate work, where we could help with 15:34:39 portdirect: agreed - would be the place to start, instead of cleaning it up externally before bringing it in 15:35:36 witek: are the current helm charts in openstack? I see them in github, is that under openstack governance? 15:36:07 sorry to be so pernikity here - just dictates wheter we should go there and start work, or pull in as a ps in openstack-helm-addons 15:36:17 portdirect: no, they are in monasca/monasca-helm repo 15:36:19 *persnickety 15:36:40 roger - who controls that? HP? 15:37:23 I think it's better to focus on the future than on the present of those charts 15:37:24 no, I'm one of the project owners, but I would prefer to contribute the work to OSH 15:37:47 HPE has started the effort 15:37:53 awesome - if you made a ps to osh-addons we could start work there? 15:38:00 i think that'd be the best way to do it 15:38:09 portdirect: why not OSH, as this is a openstack project? 15:38:36 (while the kafka and other parts can be in addons or infra) 15:38:39 that would work too provided it used the openstack hosted parts 15:40:29 i think it would make sense to first pull in the macro chart to openstack-helm-addons, and once it's been updated to match our current patterns, we could then move the separate parts to the appropriate places 15:41:01 thanks for the clarification srwilkers and portdirect 15:41:04 as you mentioned evrardjp: kafka, zookeeper, etc in infra, monasca in osh, etc 15:41:26 should I take the code as it is? 15:41:27 as long as there is a path towards being in governance, I feel better about it 15:41:40 witek: can you? (licensing) 15:41:52 apache2 15:41:58 good news :) 15:42:36 witek: where you involved in th development of those charts in their current home? 15:42:45 no 15:43:02 it was HPE work 15:43:37 ok - so we may need to sort out some issue here: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#The_Developer_Certificate_of_Origin 15:43:48 but should be relativity simple 15:44:38 i think point c should make this ok, provide one of the authors signs off on it 15:44:50 as far as I understand, it confirms the origin of the commit, has nothing to do with the license 15:45:35 ah ok 15:45:37 nice 15:46:19 look forward to seeing monasca in osh, it was really nice when i last played with it! 15:46:54 nice to hear, OK, I'll push the code then to osh-addons 15:46:59 ++ 15:47:16 #action witek push monasca-helm code to openstack-helm-addons 15:47:25 ok to move on? 15:47:34 yes, thanks 15:47:45 #topic new jobs in openstack-helm and openstack-helm-infra 15:47:50 srwilkers: floors yours 15:47:55 portdirect: witek is right there 15:48:04 so we've got some new jobs in openstack-helm and openstack-helm-infra 15:48:28 we've now got periodic/experimental multinode jobs for: 15:49:23 1. deploying software via armada, then updating said software by updating the release-uuid annotation on the pods via a values change 15:49:47 2. deploying software via armada, then generating new passphrases for said software, and updating it via armada 15:50:49 the idea being, we could use these jobs as smoke tests for verifying we could essentially do an update of charts via updating the release-uuid annotation as well as verifying the charts support some manner of updating credentials for the services 15:51:16 nice - how do the outcomes of those tests look atm? 15:51:16 that is a nice idea. 15:51:27 these jobs need a little more work (ideally something basic that exercises the services after the update), but i'm hoping this helps some of the outliers fall out so we can identify them 15:51:46 yeah - id really like to see this end up in our periodic 15:51:53 both of those are excellent tests srwilkers - thanks man 15:52:02 portdirect: they look good right now -- the chart that stands out to me currently is mariadb, as we need to support updating the root password 15:52:17 srwilkers: maybe a dumb question, but can't you just deploy, let's say keystone, twice for the same results (with different values overrides) 15:52:21 grafana was another outlier, which resulted in: https://review.openstack.org/#/c/634521/ 15:52:26 ok I can hit that this week, as we also need to fix the xtradb config 15:53:45 evrardjp: sure, you could. this stood out as a sane approach though, as i think just triggering updates to everything with something like armada makes more sense 15:53:53 that could just be me 15:54:17 another reason i used armada is that the old armada-deploy job already generated passphrase overrides for each service. it was fairly simple to just extend that 15:54:34 :) 15:54:43 Thanks for the clarification. 15:55:35 the other thing we get from this approach is an understanding of how services react when their supporting services admin credential change 15:56:15 As a heads-up srwilkers -- I'd heard that the release-uuid doesn't kick the ceph pods because the pod spec is left unchanged by it. So I'd be interested in looking over your shoulder on that and confirming whether/which pods actually do cycle from the whole set 15:56:41 yup - this is one of the things i expect to fall out of this 15:56:59 yup 15:56:59 where we need to apply the annotation at the pod level, rather than just the controller 15:57:14 ++ 15:57:22 i still vote for us getting a `./smash.sh` script :D 15:57:27 i mean 15:57:38 that simply deletes all pods in the cluster, and we can watch the fun unfold 15:57:59 just use chaoskube or something -- i've got another, unrelated job that uses it 15:58:05 its depressing how many times ive done this in a real world senario to 'shake-down' the world 15:58:06 just let it go nuts on a deployment and see what falls apart 15:58:26 osh-donkey-kong 15:58:31 :) 15:59:16 ok 1 min left 15:59:20 #topic reviews 15:59:49 we have several patches that could benefit from some extra eyes 15:59:54 https://www.irccloud.com/pastebin/oiO6PaPZ/ 16:00:02 please lets hit them 16:00:17 sorry to have run out of time, lets move over to #openstack-helm 16:00:20 thanks everyone 16:00:23 #endmeeting