15:00:09 #startmeeting openstack-helm 15:00:10 Meeting started Tue Aug 15 15:00:09 2017 UTC and is due to finish in 60 minutes. The chair is srwilkers. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:14 The meeting name has been set to 'openstack_helm' 15:00:20 o/ 15:00:24 o/ 15:00:27 #topic roll call 15:00:30 o/ 15:00:39 o/ 15:00:40 o/ 15:01:01 \o 15:01:12 hello everyone :) 15:01:21 here's the agenda for today: https://etherpad.openstack.org/p/openstack-helm-meeting-2017-08-15 15:01:33 today was holiday here. :) it seems lots of things happening over there cross the pacific ;) long meeting note. 15:01:52 got quite a bit of information on it already, but we can take a few minutes to add anything else 15:02:04 o/ (sorry late) 15:02:13 nice jayahn -- hope you enjoyed the holiday :) 15:02:45 o/ GM all 15:03:25 hey mattmceuen 15:03:31 welcome to the party 15:03:39 let's go ahead and get started 15:03:43 #topic PTG reminder 15:03:58 o/ 15:04:15 just a friendly reminder -- the PTG's coming up quickly, so wanted to call attention back to the etherpad we had running for discussions: https://etherpad.openstack.org/p/openstack-helm-denver-ptg-topics 15:04:48 is there any schedule for ptg meeting, especially when we have meetings during five days of PTG. 15:04:52 also, since we're a hosted project, we wont have an officially scheduled time. i do know myself, portdirect, lamt and alraddarla will be there throughout the entire week 15:05:16 think alanmeadows should be around too 15:05:18 we'll be responsible for identifying our own time to meet unfortunately, as we cant be put on the schedule officially 15:05:26 its hard to see him in that black fleece 15:05:30 he melds into everything 15:05:48 I would like to leave early if possible, probably on Thursday. will it be possible to have all openstack-helm meetings between Mon - Wendesday? just asking. :) 15:05:58 jayahn: absolutely 15:06:11 great. then, i will finalize my flight. :) 15:06:29 jayahn: awesome. look forward to seeing and chatting with you :) 15:06:30 jayahn: but then we miss you on friday night :( 15:06:44 yeah.. that is true. 15:06:51 i'm leaving friday night too :( 15:07:29 #topic Libvirt/OVS breakout 15:07:30 * portdirect can come out for 1 (or 8) on thurs - but has work to do on friday :( 15:07:42 portdirect: floors yours 15:08:23 hey, so I've started work on pulling libvirt and ovs out of their parent charts 15:08:37 they were odd-ducks in osh as they included the supporting infra 15:08:46 making it hard to plug in other backends 15:08:57 and when they were - they seemed like 2nd class citizens 15:09:20 this was also causeing us some trouble when we wanted to use theservice (gasp) without openstack 15:09:31 this is really good to see. 15:09:37 is there a blueprint? 15:09:44 the two ps's are up in gerrit - and I hope to have fininshed by eod 15:09:49 though reviews welcome 15:09:55 v1k0d3n: https://blueprints.launchpad.net/openstack-helm/+spec/split-nova-and-neutron-infra 15:10:13 great! thanks portdirect 15:10:52 this will also make the neutron work a lot eaier i think for onos and other sdn backends to come in 15:10:56 that makes things much more flexible. was wondering how the team was going to implement this, although it was pretty obvious this is probably the best path. 15:10:57 *easier 15:11:27 okay. +1 on breaking out these two. 15:12:17 nice. any other comments on this topic? 15:12:30 docs are going to be included as well portdirect ? 15:12:37 check the ps :) 15:13:17 i saw that. but other than just copy paste...i mean explanation on why, how this open things up to be more flexible. 15:15:22 i think a mention of the flexibility it adds would be sufficient in my eyes -- the goals always been to be pluggable, and this really brings the charts in line with the message we've been trying to sell 15:15:39 Its fits the mission statement of osh i think? 15:16:49 i think so. i think the addition of varying backends would require a bit of documentation covering any of the specifics that might shed light on what they offer, but i'd like to see those added as the additional backends are brought in 15:16:52 this is probably really easy to see for developers or those close to the project.... 15:17:21 https://github.com/openstack/openstack-helm#mission 15:17:46 however, i think it's a little lost that users struggle with OSH, and we're really trying to win over new operators and contributors. expanding on ps like these are the "ah-ha" moments that operators need. 15:18:08 referring back to the mission doesn't really explain how each knob works. 15:18:53 i think we need to balance which knobs need explaining -- there's two extremes i think. too little explanation and too much. i'm really fond of having self-documenting code and having it structured to represent that 15:19:33 +2 15:20:42 perhaps this is a perfect moment to lead into the next topic? 15:21:27 i agree with balancing knobs. but only documenting cut/paste deployment commands shouldn't really be the answer. 15:21:30 there's a few items listed under the documentation topic -- v1k0d3n portdirect, floors yours 15:21:42 #topic Documentation 15:21:45 portdirect: you could just reach back out to the community to see if someone could take over the ps and document some things for you. 15:21:46 v1k0d3n: take it away :) 15:22:05 this is a great thing for a lead to do...and then that could be a way to engage the community better, and share work. 15:22:22 v1k0d3n: a follow on ps would be great 15:22:44 though not opposed to anyone adding docs to it :) 15:23:07 ok, so to these points...i think we (collectively) could open opportunities for new contributors, and also be a bit more welcoming by asking for help with docs. 15:23:39 v1k0d3n: would be great place for you to get involved again 15:23:47 it would be nice to follow _almost_ a pair programming model where a lead contributes a large ps, and then works with a community member for providing docs. 15:23:49 as we've missed having you push work :) 15:23:58 i'm somewhat back :) 15:24:53 and as srwilkers knows...our group is starting to get more engaged. 15:24:58 im open to getting new contributors working on the docs - it'd be a great place to get started. 15:25:33 well, and if we have folks like portdirect srwilkers or others work with new contributors...people will feel like they're part of it. 15:26:13 and i think we'd gain the momentum we want/need. 15:26:23 along with solving some of the missing docs issues. 15:26:33 so srwilkers can you come up with a list of documentation gaps? 15:26:42 i can have our folks work with you to help fill in some of those... 15:27:15 i think it'd be great for people identifying them to submit bugs about the shortcomings. unfortunately its the feedback from those who can see something missing or that isnt clear that really helps shed light on what we need 15:27:43 but more communication on IRC would be good too. blueprints would be good. in fact moving to storyboard would help a lot...so some load would be distributed more with the community. 15:27:58 i want it to _feel_ like a community project...not just coming from one source. 15:28:35 v1k0d3n: could you make a list of the docs gaps and get your team on it? would be a great way to change the fear you have 15:28:47 i don't have time portdirect 15:28:53 sorry 15:29:09 :( I fear we are all in the same boat then 15:29:10 plus, if i remember correctly...i thought were were supposed to accept ps with documentation. 15:29:29 so this just executes on that plan 15:29:59 and still leaves the hard parts to good devs like yourself. and pairs you up with someone who could learn from you from the community. 15:30:39 if it's not a good idea...i'm fine with dropping it. i just think i'm seeing a bit more 3D coming to a new company, and hearing the questions directly from non-OSH devs. 15:30:54 There's already documentation in the PS. I think there's a good opportunity for follow-on documentation that describes overall design philosophy. 15:30:59 i gotta run to a meeting. srwilkers let me know what your thoughts are. 15:31:14 cheers v1k0d3n -- grab coffee on the way 15:31:21 so a one liner in the docs is enough for libvirt moving to a new chart? 15:31:22 https://review.openstack.org/#/c/493738/5/doc/source/install/developer/all-in-one.rst 15:31:29 ok...i bow out then :) 15:32:00 let's move on 15:32:27 #topic Images 15:32:33 portdirect: floors yours 15:32:40 lol 15:32:50 2 sec 15:33:20 think a copy/paste from the etherpad is relivant here: 15:33:27 The kolla 3.0.3 images have done us pretty well - though have shortcomings: 15:33:38 many severe issues are in the docker.io pushed images - and kolla will not update them. 15:33:38 - the lack of httpd/uwsgi in the containers prior to the 5.0.x series makes forward looking dev hard - and also is limiting when wanting to use internal tls (unless we go down the sidecar container route - yuk) 15:33:38 - This also make graceful handover of services on rolling upgrades a bit more janky than it has to be - apache is much better than eventlet here. 15:34:00 As a result would making and pushing new set of images make sense? we used to use the stackenetes images - as they encountered similar issues - and I'm thinking it may be time to do the same so that we can have a set of similary non-production images to use for dev and demo purposes.I 15:34:58 ive been back and forth on this one 15:35:12 but the more we've used the kolla images, the more issues we've found with them 15:35:22 new set of images, could you be more specific? 15:35:54 I'm thinking of a set of images, built from kolla-build 5.0.0 for ubuntu source 15:36:16 that would contain all the current fixes to openstack that are not in the images kolla pushed to dockerhub 15:36:28 and also have apache/uwsgi for apis 15:37:34 ah.. i got that. 15:37:39 in addtion to the reasons above - one of the main advantages of moving to a kolla-build 5.x derived image is fixed uid/gid for service users 15:37:54 which is a super big win for security 15:38:29 ++ 15:38:54 i assume these'll get built and live in quay, and those become our reference? 15:38:56 i am totally okay with building a set of images from kolla-build, not using docker.io one. 15:39:13 srwilkers: thats what I think wuld be appropriate 15:39:46 we could include the refs to making them in gh - so they were totally reproduceable 15:39:57 i'm in support of that, build new and host on quay 15:40:06 but host and donate them to the community 15:40:12 yes 15:40:12 nice, cheers lrensing 15:40:38 okay, lets give it a go and try it out 15:40:43 if i understand correctly (just for confirmaiton on my understanding) 15:40:54 * portdirect awats input 15:41:02 its something ive been thinking about as we've found other services we need to build images for 15:41:03 we start building a set of openstack images with kolla-build tool 5.0.0 15:41:12 host those images in quay 15:41:23 use that image as reference in openstack-helm project. 15:41:28 am i getting right? 15:41:32 yes 15:42:13 I can host the images while a WIP - and then once things move towards mergable push to quay 15:42:46 seems we have consensus for the most part? 15:43:08 srwilkers, lrensing, jayahn? 15:43:11 portdirect: yeah, sounds good 15:43:31 yes. just one quick question. who will be responsible for making sure we are building good ones? :) 15:43:44 * portdirect looks other way 15:43:49 will we be putting some minial check routin on image buidling process? 15:44:00 the gate in osh 15:44:15 but to confirm - these are *NOT* ment to be production images 15:44:23 yeap. i got that. :) 15:45:14 i can let you or stacey to talk with Wil, to get some basic bats test we are using internally to check images from kolla-build. 15:45:30 jayahn: that would be awesome 15:45:33 although we are not using 5.0.0... 15:45:35 :) 15:45:37 lrensing, lamt: you on board? 15:46:22 i am in support of this 15:46:33 awesome 15:46:48 let's go ahead and move on then 15:46:59 #topic neutron decomposition 15:47:03 think this was you jayahn :) 15:47:05 floors yours 15:47:20 ah. nothing special. 15:47:47 just want to check "what urgency do you guys have in mind to make it merge". :) 15:47:59 ok - s one bit of fb i have is here: https://review.openstack.org/#/c/481225/ 15:48:20 I'm really not comfortable with the logic being inserted into the configmaps 15:48:28 i saw new review on the neutron decomposition ps, which i have to make siri to think more. 15:48:34 yeah. about that. 15:49:07 i will have internal discussion tomorrow about that, and will back with our newer idea. 15:49:15 nice - cheers jayahn 15:49:30 the decomposotion model is now in all openstack charts 15:49:37 I'm fine with other knobs being added 15:49:43 just, FYI, we are kind of urgent to build an ci pipeline around SONA integration. 15:49:47 srwilkers : yes, sorry was distracted by other convo 15:49:54 but am worred that if we go to far then the templates will become a mess 15:50:21 and my gut says a 'drop-in' replacement would be better 15:50:39 than adding a lot of logic to the current template 15:50:47 so wanted to make it work from upstream, but will get you input and will think more about that.. after all, it is about making it better and simple to use. 15:50:58 +2 cheers jayahn 15:52:30 awesome 15:52:32 anything else here? 15:54:07 #topic open discussion 15:54:19 we've got a few minutes left. any other items anyone wants to chat about? 15:54:51 * portdirect has this terrible pain in all the diodes down his left side 15:55:28 alright, ill go ahead and close it out. see you all in the channel 15:55:35 #endmeeting