10:03:08 #startmeeting charms 10:03:09 Meeting started Mon Apr 23 10:03:08 2018 UTC and is due to finish in 60 minutes. The chair is gnuoy. Information about MeetBot at http://wiki.debian.org/MeetBot. 10:03:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 10:03:12 The meeting name has been set to 'charms' 10:03:17 #topic Review ACTION points from previous meeting 10:03:24 * gnuoy looks for actions 10:03:48 ok, I see no actions 10:04:07 #topic State of Development for next Charm Release 10:04:28 Right then we are working towards the 18.05 release atm 10:04:39 But there is the release of bionic before then 10:04:53 yup, 3 days time, I believe. 10:04:58 o/ 10:05:00 sorry late 10:05:12 I assume the plan is to stable backport any bionic tweaks as they come up> 10:05:12 ? 10:05:35 yes i think any blocking fixes for bionic will get stable backports until the may charm release 10:05:42 coreycb was working one those 10:05:48 Thursday is Bionic's release schedule 10:05:56 it is 10:06:09 kk 10:06:12 a charm-nova-cloud-controller fix landed today 10:06:26 Anything else people would like to highlight? 10:06:58 nope 10:07:07 ok, I shall move on... 10:07:20 #topic High Priority Bugs 10:07:33 Critical bugs: https://tinyurl.com/osc-critical-bugs 10:07:33 High priority bugs: https://tinyurl.com/osc-high-priority 10:08:28 Gosh, there are a fair few highs there 10:09:06 Anyone want to highlight any bugs they are working on? 10:09:34 I have the charm-nova-cloud-controller for bionic landed in master 10:09:43 ah, yes, thanks for that 10:09:53 I am also working on deprecating self-signed SSL management in Keystone 10:10:06 As it is causing issues for deployments which does not use that feature 10:10:20 (which is the most of our users) 10:10:34 yeah :) 10:10:45 Need some documenting and departmentaling of the propsoed patch on my part and I will ask for review asap 10:11:15 lathiat, do you want to mention the bug/reviews questions you had now? 10:11:20 Sure 10:11:24 thanks 10:11:41 Looking for some input on adding "SSL Hardening" options to charm-helpers destined for most of the HTTP service charms, details in https://github.com/juju/charm-helpers/issues/129 - hadn't had a response on that yet so wasn't sure where to raise it. 10:12:44 Not sure if people would prefer to read the above, or if I should elaborate further here? Happy to take follow-ups in the bug post-meeting. More wanted to get some attention. 10:12:57 I think this is a good topic for this meeting 10:13:01 Can we get some volunteers to review that doc 10:13:04 ? 10:13:13 yes, and discuss here 10:13:20 s/doc/comment 10:13:44 lathiat: one thing that springs to mind was some older py2's support for TLS 1.2 10:14:04 something along those lines - can't remember the detail (might be 14.04's) 10:14:11 jamespage; Yeah I also thought about that, something I planned to do when I implement it was test which distro/openstack versions did or didn't work once you twiddled those various options. 10:14:19 lathiat: +1 10:14:23 I like the idea of ssl-security-level fwiw as long as we default it to high/modern 10:14:34 secure-out-of-the-box and all that 10:15:09 gnuoy: agreed - an opinionated secure by default stance is good IMHO 10:15:14 The second main sticky point was the customer wants to be able to set the SSLCipherSuite list and that seems a little non-charmy, so wanted some thoughts on if we allowed thought, or perhaps allowed some other kidn of config-flags style option, or just pushed back on that request entirely 10:15:18 lathiat: thanks for working this btw - much appreciated 10:15:54 lathiat: I'd rather take the profiles approach 10:16:06 general helps users not shoot themselves in the foot 10:16:22 Right, but what about super-opinionated customers 10:16:46 I like the idea of profiles + config-flag overides for the crazy people 10:17:40 config-flags would allow tactical fixes while we update the cert list in the event of an urgent change 10:17:48 I can't argue with that 10:17:56 however I still don't like config-flags ;) 10:18:06 don't get me wrong, neither do I 10:18:51 lathiat: sounds like something config-flag's y is OK but with severe health warning 10:18:51 lathiat, I think your issue statement is very well thought through 10:19:04 I won't block on that... 10:19:09 * lathiat nods 10:19:15 ok thanks, i'll take that and put something together and submit for review 10:19:23 but will insist that if it gets used, we raise bugs and generate profiles! 10:19:44 yes, please. standard config-flags caveat applies 10:19:49 Secondly, looking for some input for a change I'm about to propose which enables VPNaaS for xenial-mitaka onwards. It was originally disabled in utopic (post-trusty) because OpenSwan was deprecated/removed however at the same time strongswan is promoted to main and is supported - and was supported by OpenStack even then. 10:19:50 [an initial not-up-to-date patch is here, will push an updated version post meeting with fixed tests] https://review.openstack.org/#/c/551168/ 10:20:15 The requesting user desires this to work on xenial-mitaka, but for mitaka we need to remove the neutron-l3-agent package and replace it with neutron-vpn-agent package (and service) instead. It's the same code underneath mostly for whatever implementation reason it was done as a subclass with a separate binary. This is all normal and related code already exists for trusty, but I'm just concerned about introducing that change for 10:20:15 existing xenial-mitaka installations or whether that would even be considered. Right now VPNaaS is installed on trusty-mitaka, but not xenial-mitaka. 10:20:26 Of note for Queens, they removed the neutron-vpn-agent being a subclass and separate binary and it's now just a loaded extension. But doesn't help with xenial-mitaka through pike. 10:21:09 Or rather more with xenial-mitaka since we'll be supporting that longer term 10:21:46 just wanted to get a feeling for whether that change for xenial-mitaka (well tested) is likely to be accepted or not 10:22:20 * gnuoy defers to jamespage on this as I can't remember what the deal was with the swans 10:23:05 lathiat: most of my pushback would be on viability of vpnaas as a project within openstack right now 10:23:43 if you can prove is being sustained/supported OK, then I don't have an objection to enabling is in the charms - but its been a bit on/off in the last 12 months 10:24:14 jamespage; OK, I can't really speak to that right now, I'd have to look into it. 10:24:26 lathiat: great! 10:24:28 if we assume it was, then the change would be reasonable? 10:25:09 yes - dealing with the switchout of the binary and the move to extension in l3 rather than different binary needs to be accomodated for upgrades as well 10:25:16 but in general sounds ok ish 10:25:20 yeah i've handled all that in my prepared patch 10:25:25 trusty->mitaka etc 10:25:36 and also for existing trusty-mitaka installs that are on openswan (i left it on openswan) 10:25:49 OK perfect. I'll look into that. Thanks! That's all from me. 10:25:56 kk 10:26:12 #topic Openstack Events 10:26:20 https://www.openstack.org/summit/vancouver-2018/ 10:26:24 summit not that far off now 10:26:41 I'll be doing my usual project update and helping run some forum sessions on upgrades 10:26:49 nice 10:26:52 oo, that is a nice place. Make sure to visit English Bay and do some spotting of sea planes 10:27:58 I'm going to hurtle on to the next topic unless anyone wants to highlight another event 10:28:05 #topic Open Discussion 10:28:57 anyone ? or I'm going to close this up 10:29:11 #topic Next Chair 10:29:23 tinwood is our winner! 10:29:35 I thought I might be :) 10:29:59 #endmeeting