16:02:37 <inc0> #startmeeting kolla
16:02:38 <openstack> Meeting started Wed Feb 14 16:02:37 2018 UTC and is due to finish in 60 minutes.  The chair is inc0. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:41 <inc0> now it did:)
16:02:42 <openstack> The meeting name has been set to 'kolla'
16:02:49 <mgoddard_> \o
16:02:50 <inc0> #topic w00t!
16:03:01 <gkadam_> O/
16:03:03 <inc0> good morning everyone
16:03:09 <yankcrime> hi!
16:03:14 <gema> o/
16:03:16 <paken> hi there!
16:03:28 <sadasu> hello
16:03:43 * gkadam_ 's first kolla meeting. Hello Everyone! :)
16:03:46 <mchlumsky> hi
16:03:54 <inc0> welcome gkadam_
16:04:14 <pbourke> w00t w00t
16:04:17 <gkadam_> inc0, thanks! :)
16:04:36 <pbourke> welcome gkadam_
16:04:56 <inc0> happy Valentines day;)
16:05:14 <inc0> ok let's move to actual meeting
16:05:18 <inc0> #topic announcements
16:05:43 <inc0> well, this is probably last meeting I'm leading. Everyone voted for next PTL?
16:05:53 <inc0> elections ends in few hours
16:06:43 <inc0> any community announcements?
16:06:56 <pbourke> thanks again for your service inc0
16:07:07 <inc0> :)
16:07:07 <gkadam_> inc0++
16:07:11 <gema> inc0: thanks a lot for your leadership indeed!
16:07:33 <inc0> just be as good to next ptl as you were to me
16:07:49 <inc0> that's my request
16:07:56 <inc0> allright, let's move to agenda
16:08:05 <inc0> #topic Deploying a cloud with Kolla for the RDO test days - status?
16:08:16 <inc0> dmsimard: ^
16:08:29 <pbourke> I actually added that line, unsure if dmsimard is around
16:08:40 <dmsimard> Hi, we actually just discussed it in our RDO meeting
16:08:44 <pbourke> ah there you are :)
16:09:22 <inc0> so what are we doing and how do we do it?:)
16:09:27 <dmsimard> Long story short we're going to push it until after the PTG. The timing is not really good right now with everyone scrambling to get Queens out the door
16:09:44 <dmsimard> We're still very much interested in doing it (and I hope you are too)
16:10:16 <pbourke> that probably makes sense too in that we can test using the released queens rather than an rc
16:10:39 <pbourke> dmsimard: just please don't be shy about sending us reminders to the mailing list so everyone can be prepared
16:10:41 <dmsimard> Something like that, the stable repos will be out by then as well
16:10:50 <pbourke> dmsimard: will you be at the PTG?
16:11:03 <dmsimard> Unfortunately not this time around but some of my colleagues will be there
16:11:16 <dmsimard> I'll hopefully be in Vancouver though
16:11:42 <pbourke> kk
16:12:18 <dmsimard> Don't be shy to poke me for updates either, I'm on a lot of threads so sometimes it's hard to keep up :)
16:12:27 <pbourke> I hear you
16:12:31 <dmsimard> (just like you pinged me right now!)
16:13:49 <pbourke> ok so we'll pick it up again after the PTG
16:14:15 <inc0> ok, so let's move on then
16:14:25 <inc0> thanks dmsimard for update
16:14:35 <inc0> #topic keystone uuid removal in rocky (pbourke)
16:14:38 <dmsimard> Anytime
16:14:50 <inc0> pbourke: you're on
16:15:13 <pbourke> ok so as people may have noticed keystone is broken in kolla master
16:15:34 <pbourke> they moved onto rocky and removed uuid tokens
16:16:00 <pbourke> luckily for us, fernet works fine in kolla so it will be a small patch to update our defaults
16:16:06 <pbourke> that said, we have two tasks as I see it
16:16:26 <pbourke> 1) reconfigure/upgrade for people coming from previous releases
16:16:42 <pbourke> 2) what to do with our queens master as is before we branch
16:16:59 <pbourke> 2) may not be an issue as the gates still seem to be working though im not sure how...
16:17:28 <pbourke> does this make sense to people?
16:18:17 <inc0> well...how it's possible that gates work? oO
16:18:36 <inc0> also, does that mean we can get rid of memcached?
16:18:36 <pbourke> yeah I think I need to figure that out :/
16:18:51 <pbourke> I think horizon may still need it?
16:19:17 <inc0> tbd, but memcache with uuid was huge security risk
16:19:23 <pbourke> anyway, just wanted to make people aware. Will try sync up with Jeffrey4l wrt branching
16:20:28 <inc0> thanks for heads up
16:21:05 <inc0> pbourke: anythin else on that topic?
16:21:13 <pbourke> dont think so :)
16:21:17 <inc0> kk
16:21:22 <inc0> #topic yankcrime - haproxy config
16:21:30 <inc0> yankcrime: you have the floor
16:21:34 <yankcrime> wow
16:21:35 <yankcrime> hi!
16:21:42 <inc0> hello:)
16:21:57 <gkadam_> hello yankcrime :)
16:21:59 <yankcrime> ok so here's the change i proposed: https://review.openstack.org/#/c/534834/
16:22:29 <yankcrime> it's been languishing for a while, mostly because of a subject which pbourke brought up on openstack-dev
16:22:50 <pbourke> yeah im sort of to blame here...
16:23:18 <pbourke> essentially the patch looks fine, but it sort of re-raised the whole 'kolla only provides essential config' philosophy we have going
16:23:36 <yankcrime> so in my case, the suggestion isn't arbitrary - it's driven by an actual use case, and one which i think is fairly common
16:23:42 <yankcrime> hence the associated blueprint: https://blueprints.launchpad.net/kolla-ansible/+spec/haproxy-listener-extra-options
16:23:54 <inc0> pbourke: well we don't have config overrides for haproxy
16:24:00 <pbourke> yeah I get that
16:24:20 <pbourke> though in the past we've gone with the 'with_first_found' or whatever the ansible directive is for these kind of files
16:24:31 <pbourke> overall I dont mind hugely I just want to be consistent
16:24:32 <mgoddard_> is there any sane way that config overrides could work for haproxy?
16:24:37 <pbourke> as others have had similar patches rejected in the past
16:24:42 <yankcrime> right, and i'm guessing non-ini merge_config is a long ways off being viable for stuff like haproxy
16:24:42 <pbourke> which doesn't seen fair
16:24:48 <pbourke> *seem
16:24:55 <inc0> mgoddard_: you can use your own config completely
16:25:10 <mgoddard_> yeah, but I don't want to have to maintain a clone of the template
16:25:14 <inc0> so worst case you can do kolla-ansible genconfig, get default, edit and make ansible use it
16:25:21 <yankcrime> haproxy's configuration is probably worst-case for having to completely manage your own configuration outside of kolla-ansible though, no?
16:25:36 <inc0> yeah it's not ideal
16:26:23 <inc0> that being said, as pbourke mentioned, having completelty extensible config is also hard/impossible
16:26:50 <mgoddard_> it is, but in cases where config can't be overridden, it's more justified right?
16:27:10 <inc0> well in .ini confs we wouldn't accept that
16:27:14 <inc0> here, we debate:)
16:27:31 <inc0> I'm actually for accepting this one
16:27:50 <mgoddard_> what if the haproxy config was more modular, and autogenerated for each service from snippets
16:28:00 <yankcrime> well the conversation is more about whether or not you could see this feature, which is justified with a use-case, is worth merging
16:28:15 <inc0> mgoddard_: if you could implement sth like that, it sounds great
16:28:53 <pbourke> my current thinking on it is there's no one right answer
16:29:09 <pbourke> the real solution is probably somewhere in between the two extremes
16:29:33 <inc0> yeah I agree pbourke that's why I would accept this one and debate proper full solution
16:29:36 <inc0> PTG?:)
16:29:44 <mgoddard_> that sounds like a good compromise
16:29:45 <pbourke> yeah I think that's a good course of action
16:30:05 <pbourke> +2 so for your change yankcrime, sorry again for the procrastination
16:30:19 <pbourke> thanks for sticking with it
16:30:25 <yankcrime> no worries pbourke, thanks for helping it move along
16:31:01 <inc0> ok
16:31:05 <inc0> #topic open discussion
16:31:10 <inc0> anyone?
16:31:12 <paken> Hi there
16:31:21 <inc0> hey:) go ahead paken
16:31:24 <paken> since this is my first meeting, I would like to introduce myself
16:31:33 <gkadam_> hey paken , same here
16:31:51 <paken> My actual name is Paco Bernabé (spaniard living/working in The Netherlands)
16:32:03 <paken> Working at SURFsara, where we have several clusters
16:32:20 <paken> We have the plan of using Openstack to virtualize all these clusters
16:32:35 <paken> and we are looking at Kolla-Ansible as an option for deployment
16:32:51 <paken> I have submitted last week an small change request
16:33:05 <paken> but I have some other related the Ansible playbooks
16:33:18 <paken> since this is where I have started looking at
16:33:41 <inc0> paken: so right now we are in feature freeze - close to release and only bufixes are accepted
16:33:46 <inc0> for next week or so
16:33:46 <paken> so, I hope to keep on contributing on this.
16:33:55 <paken> ok, I understand
16:34:14 <inc0> but awesome, thank you
16:34:29 <inc0> when we branch out queens, we're open for business again
16:34:39 <pbourke> paken: feel free to post a link to your change(s) if you'd like to get more progress with it
16:35:04 <gkadam_> let me introduce my self as well. I am currently working in to openstack tech support at Red Hat
16:35:05 <paken> ok, great. I’ll keep on making the list and submitting the changes
16:35:06 <inc0> also if you run into issues during your deployments, make sure to look for help on our channel
16:35:26 <paken> sure, thanks
16:35:52 <inc0> gkadam_: we have quite a few hatters in our community:
16:35:57 <pbourke> Introductions are a nice idea actually, nice to get to know new members
16:36:10 <gkadam_> just came accross the dployment tool called infrared which i tried this week , and learnt that it somehow is using Kolla , tyring to learn more in to container world
16:36:37 <gkadam_> also, i am looking for some easy fixes to start with
16:36:39 <inc0> agree pbourke we should make it standard part of meeting
16:36:42 <hrw> gkadam_: by 'openstack tech support' you mean rhosp?
16:36:43 <gkadam_> as m not a seasoned programmer
16:36:48 <gkadam_> hrw, yep
16:37:10 <hrw> gkadam_: one day I have to check how rhosp looks
16:37:15 <inc0> gkadam_: I'm not familiar with infrared, but tripleo uses kolla images
16:37:18 <gkadam_> hrw, :D
16:37:29 <egonzalez> gkadam_ search for wish list bugs in launchpad
16:37:38 <gkadam_> egonzalez, ack
16:37:58 <gkadam_> inc0, http://infrared.readthedocs.io/en/infrared_v1/introduction.html
16:38:09 <egonzalez> But now we need for help in testing upgrades to queens
16:41:14 <jmccarthy> egonzalez: I'm trying that out a bit actually at the moment, maybe we can chat some more afters
16:42:50 <egonzalez> jmccarthy sure
16:43:00 <inc0> ok, anyone else wants to talk about anything?:)
16:43:07 <paken> one question only
16:43:27 <paken> although you are feature freeze, changes can still be submitted?
16:43:33 <pbourke> paken: yes
16:43:38 <egonzalez> Yes but not merged
16:43:42 <pbourke> they'll just be held / -1'd until branching
16:43:49 <paken> cool, got it, thanks
16:43:51 <egonzalez> Only bug fixes
16:44:08 <pbourke> i have a small announcement also, I finally got ceph-ansible working with kolla :)
16:44:19 <inc0> oh, cool!
16:44:20 <egonzalez> Yay!
16:44:23 <inc0> was it hard?
16:44:23 <paken> nice
16:44:24 <spiette_> \o/
16:44:28 <pbourke> very minimal changes actually
16:44:34 <pbourke> which Im very pleased about
16:44:49 <pbourke> so maybe I'll prepare a demo for the PTG and we can go from there
16:44:55 <inc0> cool, then, do we want to deprecate ceph in Rocky?
16:45:03 <mchlumsky> Hi, I'm also new here. I work at Ubisoft in Montreal. I have a question regarding what pbourke mentioned regarding 'with_first_found' for custom configs. What was wrong with this approach?
16:45:29 <pbourke> inc0: unless objections I think it would be a good objective
16:45:37 <inc0> mchlumsky: well you'd need to have your own copy of whole config file and keep it updated as defaults change
16:45:38 <paken> inc0: does that mean that that the tasks in external_ceph.yml won’t be used anymore?
16:45:40 <gema> pbourke: let's discuss at PRG
16:45:41 <gema> PTG
16:45:49 <pbourke> paken: we could keep external ceph stuff
16:45:52 <gema> what the changes are and how realistic it is for production
16:45:56 <inc0> pbourke: well I'd go and mark it as deprecate now
16:46:02 <inc0> now begin before Q is released
16:46:08 <pbourke> good point
16:46:08 <gema> pbourke: I thought we had until the end of luminous to move :)
16:46:09 <egonzalez> paken ceph will likely be external ceph
16:46:20 <paken> ok
16:46:30 <gema> hrw: we'll need to look into adding ARM64 images to ceph-ansible sources asap
16:46:35 <inc0> while it can take more than one release, it will make it possible to remove it during rocky
16:46:37 <hrw> gema: make a card
16:46:43 <gema> hrw: you got it
16:46:46 <ktibi> pbourke, the final goal is to use ceph-ansible started by kolla ?
16:46:48 <pbourke> gema: hrw: ceph-ansible can use any images afaik
16:46:49 <hrw> gema: ok
16:47:01 <gema> pbourke: but will kolla keep producing them?
16:47:08 <egonzalez> We can deprecate and remove when ready, not need to be next release
16:47:17 <inc0> well we can keep producing them tbh
16:47:20 <pbourke> ktibi: the goal is to stop having to maintain ceph orchestration in kolla. ceph-ansible may be a means to this end
16:47:33 <inc0> right egonzalez
16:47:54 <gema> pbourke, inc0: ok, understood, let's talk about it at PTG and maybe do it in Rocky
16:47:59 <inc0> that's why i'd be ok with marking it deprecated now and saying that "near future"
16:48:08 <gema> inc0: yep, sounds good
16:48:11 <egonzalez> +1
16:48:11 <inc0> near future could be Rocky
16:48:32 <ktibi> pbourke, right but is it kolla which use ceph-ansible ? or need to deploy a ceph cluster before kolla.
16:48:34 <inc0> pbourke: will you make a change?:) release note with deprecation? and maybe deprecation warning
16:48:40 <hrw> external ceph may one day mean end of ceph packaging for me ;D
16:48:41 <mchlumsky> inc0, that's true but I found it very helpful when I needed to add custom keystone configuration to support openid connect in keystone
16:48:54 <inc0> ktibi: kolla itself can install ceph
16:48:56 <pbourke> inc0: sure lets do it
16:49:12 <inc0> we're talking about removing this ability because we have hard time supporting it
16:49:12 <ktibi> inc0, ok great :D
16:49:13 <mchlumsky> inc0, by custom keystone configuration, I meant the wsgi config
16:49:18 <pbourke> mchlumsky: I would totalyl be ok with allowing with_first_found for every config
16:49:32 <pbourke> mchlumsky: the issue is how we handle the ones we do provide
16:50:04 <inc0> mchlumsky: right, you can do it, issue was with haproxy which itself is very long file
16:50:12 <inc0> hard to keep track of changes
16:50:44 <egonzalez> Re haproxy i was thinking on doing a macro to generate automatically the file, allowing some extra options
16:50:51 <hrw> ktibi: I think that it can be "deploy ceph using ceph-ansible, deploy openstack using kolla-ansible" or "deploy ceph+openstack using kolla-ansible which calls ceph-ansible to do ceph part"
16:51:01 <inc0> also, don't tell me Anthem will run on Kolla mchlumsky ;)
16:51:06 <egonzalez> Something like kolla image install macro
16:51:31 <pbourke> hrw: yeah, I haven't thought hugely about how we'd integrate the two projects so thoughts here are appreciated
16:51:40 <pbourke> inc0: lol
16:52:02 <hrw> pbourke: I think that first step would be first method and then doing second way
16:52:27 <inc0> correction, anthem is EA
16:52:36 <inc0> soo...assasins creed?;)
16:52:44 <pbourke> i'll be ok with a free copy of origins
16:52:45 <ktibi> hrw yes I think all options are good. But the configuration of pools or anythink about openstack need to be in kolla no ?
16:53:00 <inc0> anyway, I think config issue should be discussed on PTG
16:53:09 <hrw> ktibi: no idea how ceph is deployed. my biggest setup is all-in-one+compute
16:53:14 <mchlumsky> pbourke, the best part about overriding wsgi-keystone.conf (for me) was that I could override it with a slightly modified jina2 template and it would still do the rendering. That was awesome! :)
16:53:18 <inc0> pbourke: would you mind running this session?
16:53:28 <pbourke> inc0: sure thing
16:53:34 <inc0> cool
16:53:44 <ktibi> hrw I use kolla + ceph in production so it's very important to me ^^
16:53:56 <hrw> ktibi: 99% of deployments do probably
16:53:58 <pbourke> ktibi: we'll be sure to have a migration path
16:54:03 <pbourke> that is essential
16:54:22 <inc0> ktibi: look how external ceph is handled today
16:54:26 <mgoddard_> when do we expect ceph to be removed from kolla?
16:54:30 <inc0> that's going to be the thing
16:54:44 <inc0> mgoddard_: we're discussing rocky
16:54:56 <mgoddard_> is it deprecated?
16:54:57 <inc0> but that's only if we manage to implement robush upgrade path
16:55:00 <mchlumsky> inc0, I can't discuss such things... but I'm here so....
16:55:23 <inc0> haha, no worries, I'll keep that in mind when playing next game;)
16:55:47 <inc0> (number of cool use cases for kolla grows!)
16:55:48 <mchlumsky> :)
16:55:55 <ktibi> inc0, yep I waited production ready for ceph-ansible for use it. Now I think I'll maybe use a external ceph (external but on compute :p)
16:56:22 <inc0> ktibi: external only means "not deployed by us"
16:56:33 <pbourke> so we should be clear about this deprecation
16:56:42 <inc0> yes, release note and warning
16:56:44 <pbourke> there will be a full cycle of deprecation
16:56:59 <inc0> at least one full cycle
16:57:01 <pbourke> and it prob should not be done if a lot of community members have reservations
16:57:19 <ktibi> inc0, yes it's why I say on compute ^^
16:57:20 <pbourke> so I'll make sure to circulate this review widely for feedback
16:57:36 <pbourke> maybe should have a spec, dunno
16:57:39 <inc0> well after Boston PTG I think everyone was kinda on board that we need to be careful but should do it
16:57:51 <inc0> pbourke: review it on PTG
16:58:08 <hrw> pbourke: spec sounds good
16:58:41 <inc0> allright, we're at the end of meeting
16:58:59 <inc0> have a great day/evening everyone and remember to vote for PTL if you haven't done so
16:59:06 <yankcrime> thanks all! o/
16:59:06 <inc0> #endmeeting kolla